コードの速度を測定するとなると、意外と準備とか評価が面倒ですが、JavaScriptの場合はjsPerfというサイトがあります。

使い方

まずは、GitHubアカウントが必要なので、連携ログインします。すると、入力フォームが出てきます。

Your details…作者の情報。なくても動きます。
Title…テストのタイトル（必須）
Slug…テストに振るURL（必須、既存のと重複不可）
Preparation code HTML…テスト用に準備しておくHTML。DOM操作のテストをする場合の準備や、あるいは<script>でJavaScriptライブラリを読み込んでおくなどに使えます。
Define setup for all tests…時間測定に入らない、事前準備の部分。必要な関数・変数を用意するなどに使いましょう。
Define teardown for all tests…時間測定に入らない、後片付けの部分。生成したDOM要素を処分するなど、必要な時があるかもしれません。
テストケース…比較対象を書いていきます。

これを入れれば、あとは「Run」を押すだけで、繰り返し測定、標準偏差の算出など、自動的に進んでいきます。同じURLにアクセスすれば、ブラウザを変えての測定もいとも簡単にできてしまいます。

注意点

「暗号の安全性確保のために処理速度がかかる必要がある、あるいは複数の処理対象で有意な時間差を作ってはいけない」というような例を除けば、「速くなることがデメリットになる」場面はほぼ存在しません。

ただし、速くしてどれだけのメリットがあるのかは、状況によって違ってきます。たとえば、ブラウザ上で行うイベント処理などは、速い方がいい…のは間違いないのですが、ブラウザが1フレームを描画し直す1/60秒に間に合うのであれば、それ以上高速化してもユーザーへのメリットはほぼありません。

ということで、自分の考える使い方は以下のようなところです。

悪魔に魂を売ってでも、速さが必要な場合…思考ルーチンや仮想DOMのメインループなど、速さがプロダクトの価値そのものに直結する場合は、徹底的に考えて書く必要があります。
関数などでラップできるような場合…関数化できる操作であれば、適切なテストを行いつつ、関数外には影響を及ぼさずに内部だけの最適化が可能です。
地雷を避ける場合…JavaScriptでは、ときおり「書き方によって数十倍以上遅くなってしまう」ようなことがあります（実際に遭遇した例）。高速にチューニングする必要がないような場面でも、さすがに数十倍遅いものは選ばないほうがいいでしょう。

逆に、clickハンドラ内のコードを書くときに、「スコープの遠い変数が遅い」とか「i++と++iは速度的にどっちがいいのか」なんてのを気にするのは、やりすぎです。