次の手法のいずれかがパフォーマンスを追加するのだろうかと思います。
!!variable - jquery とそのプラグインでこれを確認 - bool にキャスト
null == 変数 - これは、2 番目の等号を見逃した場合に役立ちます。しかし、SOの誰かが、これはgzipの最適化によるものだと主張しました
変数の縮小と縮小 - これについて私は IE に興味があります。変数の縮小の恩恵を受けることができますか
どれが本当でどれが役に立たない?
次の手法のいずれかがパフォーマンスを追加するのだろうかと思います。
!!variable - jquery とそのプラグインでこれを確認 - bool にキャスト
null == 変数 - これは、2 番目の等号を見逃した場合に役立ちます。しかし、SOの誰かが、これはgzipの最適化によるものだと主張しました
変数の縮小と縮小 - これについて私は IE に興味があります。変数の縮小の恩恵を受けることができますか
どれが本当でどれが役に立たない?
はい、自分でやろうとせずに優れたGoogle の Closure Compiler のようなミニファイヤを使用すると、ミニファイはより小さなファイルを作成するために機能します。
実行パフォーマンスに関しては、ゲインは目立たず、方法によってはわずかにマイナスになることさえあります。しかし、それは目標ではありません。目標は帯域幅を節約することです。
実証済みのものよりも優れた機能を実行できるという十分な自信がない限り、自分でミニファイヤを作成する理由はありません。それは簡単な作業ではありません。
さて、あなたの最初の特定のトリック (最初の 2 つの命題) を見ると、それらは縮小にはほとんど役に立ちません。
JS の縮小は JS エンジンとは無関係であることに注意してください。IE 固有の問題はありません。
縮小作業。主な目標は、結果の JS ファイルを小さくして、ページが jS リソースをロードするときに帯域幅をあまり使用しないようにすることです。Google の Closure Compiler などのミニファイアは、コードをさらに圧縮できるデッドコードの削除などのタスクを実行することで、さらに先に進むことができます。
アップデート
最初の 2 つの例は縮小には実際には適用されず、パフォーマンスの節約はごくわずかです。前述のように、Google の Closure Compiler はデッドコードの削除を実行します。しかし、関数と定数のインライン化を実行することもできます。これにより、パフォーマンス上の利点が得られる可能性がありますが、私の知る限り、最も積極的な最適化でさえ、これ以上のことはできません。つまり、コードをよりパフォーマンスの高いコードに変換するミニファイヤを私は知りません。これが IE にどの程度の利益をもたらすかはわかりませんが、コードがよりパフォーマンスの高いコードに積極的に変換されているわけではないので、それほど大きな影響はないと言えます。おそらく、変数の縮小は、ブラウザー内のシンボル テーブルで使用されるメモリが少なくなることを意味しますが、私はそうしません。