HTML / Javascriptミニファイが有益な理由

HTTPプロトコルが既にgzipデータ圧縮をサポートしているのに、なぜHTML / Javascriptミニファイが有益なのですか？

Javascript / HTMLミニフィケーションは、不要な空白を削除し、おそらく変数をそれぞれ数文字に名前変更することにより、Javascript / HTMLファイルのサイズを大幅に削減できる可能性があることを理解していますが、LZWアルゴリズムは、繰り返しが多い場合は特にうまくいきません文字（例：たくさんの空白？）

一部のJavascript縮小ツールは、サイズを縮小するだけではありません。たとえば、Googleのクロージャーコンパイラは、関数をインライン化したり、他の分析を行ったりして、コードのパフォーマンスを改善しようとします。ただし、Javascriptミニファイの主な目的は通常、ファイルサイズを小さくすることです。

また、コードの難読化など、パフォーマンス以外に縮小したい他の理由があることも理解しています。ただし、パフォーマンスの向上とファイルサイズの削減ほど、その理由は通常強調されません。たとえば、Closure Compilerは難読化ツールとしてではなく、コードサイズリデューサーおよびダウンロード速度エンハンサーとして宣伝されています。

それでは、gzip圧縮でファイルサイズをすでに大幅に削減している場合、Javascript / HTMLミニフィケーションから実際にどれだけのパフォーマンスが得られますか？

gzip圧縮には独自のオーバーヘッド（CPU）があるためです。縮小化は、CPUに影響を与えることなく適用できる最初の「低負荷」圧縮です。

これらは取るに足らないように思えるかもしれませんが、規模が関係する場合、数値はすぐに意味をなします。

さらに、縮小化により、gzip を減らすことができます。

一般に、gzipは一般的なアルゴリズムであり、特定の入力に特に適合していないため、ミニフィケーション+ gzipは通常より良い結果をもたらしますが、minificatorはそのコンテンツを認識し、一般的な圧縮アルゴリズムではできない作業を実行できます。一般的に圧縮することはできませんが、損失を伴うこともできます（コメントと空白を完全に排除します-これはこのデータを100％圧縮しますか？）

パフォーマンス上のメリットはあまりありませんが、帯域幅の使用量は削減されます。縮小（およびリクエストの数を減らすためのcssスプライトの使用）によってjs（およびcss）ファイルから数KBを削ることができ、1か月後に1千人のユーザーにサービスを提供している場合、1か月後に帯域幅が大幅に削減されます。

Webアプリケーションで行う最も高価なことの1つは、送信することです。CPUサイクルで料金を支払っている場合、ネットワーク経由で送信するものを少なくすることは、ほとんど常に正味の利益です。

さらに、これを裏付ける科学的なものは何もありませんが、縮小ツールがドメイン固有であり、javascriptをgzipよりも圧縮するように調整できる場合、縮小ツールはおそらくgzipよりもjavascriptを圧縮できると期待していますは汎用ツールであり、途中で妥協します。