Gzip vsミニファイ
先日、JavascriptとCSSを縮小することと、Gzipを使用することを好む人について、やや活発な議論がありました。
この人をXと呼びます。
Xは、Gzipがファイルを圧縮するので、Gzipはすでにコードを縮小していると言いました。
同意しません。 Zipはlosslessファイルサイズを縮小する方法です。ロスレスとは、元のファイルを完全に復元する必要があることを意味します。つまり、スペース、不要な文字、コメントコードなどを復元できるように情報を保存する必要があります。より多くを圧縮する必要があるため、これはより多くのスペースを占有します。
テストする方法はありませんが、このコードのGzipは次のように信じています。
.a1 {
background-color:#FFFFFF;
padding: 40px 40px 40px 40px;
}
このコードのGzipよりも大きくなります：
.a1{body:background-color:#FFF;padding:40px}
この正誤を証明できる人はいますか。
そして、「それは私がいつも使っていることだから正しい」と言ってはいけません。
ここで科学的証拠を求めています。
テストは非常に簡単です。私はあなたのjsを別のファイルに入れ、gzip -9を実行しました。結果は次のとおりです。これは、Cygwinおよびgzip 1.3.12を実行しているWinXPマシンで実行されました。
-rwx------ 1 xxxxxxxx mkgroup-l-d 88 Apr 30 09:17 expanded.js.gz
-rwx------ 1 xxxxxxxx mkgroup-l-d 81 Apr 30 09:18 minified.js.gz
実際のJSの例を使用したさらなるテストがあります。ソースファイルは「common.js」です。元のファイルサイズは73134バイトです。縮小すると、26232バイトになりました。
元のファイル：
-rwxrwxrwx 1 xxxxxxxx mkgroup-l-d 73134 Apr 13 11:41 common.js
縮小ファイル：
-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d 26232 Apr 30 10:39 common-min.js
-9オプションでgzip圧縮された元のファイル（上記と同じバージョン）：
-rwxrwxrwx 1 xxxxxxxx mkgroup-l-d 12402 Apr 13 11:41 common.js.gz
-9オプションでgzip圧縮された縮小ファイル（上記と同じバージョン）：
-rwxr-xr-x 1 xxxxxxxx mkgroup-l-d 5608 Apr 30 10:39 common-min.js.gz
ご覧のように、さまざまな方法には明確な違いがあります。最善の策は、縮小とgzipの両方を行うことです。
以下は、私のウェブサイトの「実際の」CSSファイルを使用して、しばらく前に行ったテストの結果です。 CSS Optimiser は縮小に使用されます。 Ubuntuに付属する標準のLinuxアーカイブアプリがGzippingに使用されました。
オリジナル：28,781バイト
最小化：22,242バイト
Gzip圧縮：6,969バイト
Min + Gzip：5,990バイト
私の個人的な意見は、最初にGzippingに行くことです。それが明らかに最大の違いをもたらすからです。縮小に関しては、あなたの仕事の仕方に依存します。さらに編集するには、元のCSSファイルを保持する必要があります。すべての変更の後にそれを縮小するのが面倒でない場合は、それを実行します。
（注：ファイルを提供するときに「オンデマンド」でミニファイヤを介してファイルを実行したり、ファイルシステムにキャッシュしたりするなど、他のソリューションがあります。
これをテストするときは注意してください。CSSのこれらの2つのスニペットは非常に小さいため、GZIP圧縮の恩恵を受けません。GZIPの小さなヘッダーだけを追加しても、得られるメリットは失われます。実際には、これほど小さいCSSファイルはなく、圧縮することを心配しません。
minify + gzipはgzip以外の圧縮も行います
元の質問への答えは、はい、minify + gzipは単なるgzipよりも多くの圧縮を獲得します。これは、重要な例（つまり、数百バイトを超える有用なJSまたはCSSコード）に当てはまります。
これが有効な例については、 grab Jquery source code を縮小および非圧縮で使用し、gzipで圧縮してから見てください。
Javascriptは、最適化されたCSSよりも縮小化の恩恵をはるかに受けますが、それでも利点はあります。
推論：
GZIP圧縮はロスレスです。これは、正確な空白、コメント、長い変数名などを含むすべてのテキストを保存する必要があるため、後で完全に再現できることを意味します。一方、縮小は損失が大きくなります。コードを縮小すると、コードからこの情報の多くが削除され、GZIPが保持する必要のある情報が少なくなります。
- ミニフィケーションは、不要な空白を破棄し、構文上の理由で必要な場合にのみスペースを残します。
- 縮小はコメントを削除します。
- コードの縮小により、副作用のない場所で識別子名を短い名前に置き換えることができます。
- コードの縮小は、コードを実際に解析することによってのみ可能になる、コードに対する些細な「コンパイラー最適化」を行う場合があります
- CSSミニフィケーションは、冗長なルールを排除したり、同じセレクターを持つルールを結合したりする場合があります。
あなたが正しい。
縮小することとgzipすることは同じではありません（その場合は同じと呼ばれます）。たとえば、これをgzipすることは同じではありません。
var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;
縮小するよりも次のようになります：
var a = null;
もちろん、ほとんどの場合、単に縮小またはgzipするよりも最初にGzipを縮小するのが最善の方法だと思いますが、コードによっては両方を行うよりも良い結果が得られる場合もあります。
Gzipエンコードが有利なしきい値があります。一般的なルールは次のとおりです。ファイルが大きいほど、圧縮とgzipが勝ちます。もちろん、最初に縮小してからgzipで圧縮できます。
しかし、長さ100バイト以下の小さなテキストでgzipとミニファイについて話している場合、「客観的な」比較は信頼性がなく、無意味です-ベンチマークの標準的な手段を確立するためのベースラインテキストを出さない限り、 Lorem Ipsumタイプに似ていますが、JavascriptまたはCSSで記述されています。
Fat-Free Minify （PHP）code（単に空白やコメントを取り除き、変数を短縮せず、noを使用して、jQueryとMooToolsの最新バージョン（非圧縮バージョン）のベンチマークを提案させてください。 baseX-encoding）
Minifyとgzip（保守的なレベル5圧縮）とminify + gzipの結果は次のとおりです。
MooTools-Core
-------------
Baseline 102,991 bytes
Minified 79,414 (77.1% of original)
Gzipped 27,406 (26.6%)
Minified+Gzipped 22,446 (21.8%)
jQuery
------
Baseline 170,095
Minified 99,735 (58.6% of original)
Gzipped 46,501 (27.3%)
Minified+Gzipped 27,938 (16.4%)
誰かが銃を飛ばす前に、これはJSライブラリの戦いではありません。
ご覧のとおり、minifying + gzippingを使用すると、圧縮率が向上します大きなファイルで。コードの縮小には利点がありますが、主な要因は、元のコードに存在する空白とコメントの量です。この場合、jQueryにはさらに多くの機能があるため、より適切な縮小（インラインドキュメント内のより多くの空白）が得られます。 Gzip圧縮の強みは、コンテンツにどれだけの繰り返しがあるかです。そのため、gzipと縮小の関係ではありません。彼らは物事を異なる方法で行います。そして、両方を使用することで両方の長所を活用できます。
両方を使用しないのはなぜですか？
マングリングに言及する人は誰もいなかったので、結果を投稿しています。
UflifyJSを使用して縮小化とGzipを使用することで思いついた図をいくつか示します。約20 MBのファイルがあり、約2.5 MBでコメントとすべてを連結しました。
連結ファイル2.5MB
uglify({
mangle: false
})
マングルせずに縮小：929kb
uglify({
mangle: true
})
縮小およびマングル：617kb
これらのファイルを取得してgzipすると、それぞれ239 kbと190 kbになります。
テストは簡単です。cssのテキストをテキストファイルに入れ、Linuxのgzipなどのアーカイバを使用してファイルを圧縮するだけです。
私はこれをやったばかりで、最初のcssのサイズは184バイトで、2番目のcssのサイズは162バイトです。
そのため、gzip圧縮されたファイルでも空白が問題になりますが、この小さなテストからわかるように、本当に小さなファイルの場合、圧縮ファイルのサイズは元のファイルのサイズより大きくなる場合があります。
これは、例のサイズが非常に小さいためです。大きなファイルの場合、gzipを実行すると小さなファイルが取得されます。
これをテストする非常に簡単な方法があります：空白のみで構成されるファイルと、実際に空のファイルを作成します。次に、両方をGzipし、サイズを比較します。空白を含むファイルはもちろん大きくなります。
もちろん、レイアウトやその他の重要なものを保持し、不要なジャンク（空白、コメント、冗長なものなど）を削除する「人間の」不可逆圧縮は、ロスレスgZip圧縮よりも優れています。
たとえば、マークや関数名のようなものは、意味を説明するために特定の長さである可能性が高いでしょう。これを1文字長の名前で置き換えると、スペースを節約でき、ロスレス圧縮では不可能です。
ところで、CSSには CSSコンプレッサー のようなツールがあります。
ただし、「損失のある最適化」とロスレス圧縮を組み合わせると、最良の結果が得られます。
もちろん、テストすることができます-ファイルに書き込み、 zlib でgzipします。 「gzip」ユーティリティプログラムを試すこともできます。
質問に戻ります-ソースの長さと圧縮結果との間に明確な関係はありません。キーポイントは「エントロピー」です（ソースの各要素の違い）。
ですから、それはあなたのソースがどのようにあるかに依存します。たとえば、多くの連続したスペース（例、> 1000）は、少数（例、<10）のスペースと同じサイズに圧縮されます。
これは、2つのファイルをgzip圧縮したときの結果です
bytes File
45 min.txt
73 min.gz
72 normal.txt
81 normal.gz