Gzipとminify

先日、Gzipの使用を好む人と比較して、JavaScriptとCSSを縮小することについて、やや活発な議論がありました。

この人をXと呼びます。

Xは、Gzipはファイルを圧縮するので、コードをすでに縮小化していると述べました。

同意しません。Zipは、ファイルサイズを縮小するための無損失の方法です。ロスレスとは、元のファイルを完全に復元する必要があることを意味します。つまり、スペース、不要な文字、コメント付きコード、その他すべてを復元できるように情報を保存する必要があります。より多くを圧縮する必要があるため、より多くのスペースを必要とします。

私にはテストの方法はありませんが、このコードの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オプティマイザーは縮小に使用されます。Ubuntuに付属する標準のLinuxアーカイブアプリがGzippingに使用されました。

オリジナル：28781バイト
縮小さ：22242バイト
GZIP形式：6969バイト
分+ gzipは：5990のバイト

私の個人的な意見としては、Gzipを最初に使用することです。ミニファイに関しては、あなたがどのように働くかに依存します。後で編集するには、元のCSSファイルを保持する必要があります。それが変更のたびにそれを縮小することを気にしないなら、それのために行きます。

（注：他のソリューションもあります。たとえば、ファイルを提供するときに「オンデマンド」でミニファイアを介して実行したり、ファイルシステムにキャッシュしたりします。）

これをテストするときは注意してください。CSSのこれら2つのスニペットは非常に小さいので、GZIP圧縮のメリットはありません。GZIPの小さなヘッダーとフッター（約20バイトのオーバーヘッド）を追加するだけでは、得られる利益が失われます。実際には、CSSファイルはこれほど小さくなく、圧縮について心配する必要はありません。

minify + gzipは、gzipだけでなく他のものも圧縮します

元の質問への答えは、はい、minify + gzipはgzipだけよりもかなり多くの圧縮を得るでしょう。これは重要な例（つまり、数百バイトを超える有用なJSまたはCSSコード）に当てはまります。

これの実際の例としては、圧縮されていない圧縮されたJqueryソースコードを入手し、gzipで圧縮してから見てください。

Javascriptは、十分に最適化されたCSSよりも縮小化から多くのメリットを得ますが、それでもメリットがあることは注目に値します。

推論：

GZIP圧縮はロスレスです。つまり、正確に空白、コメント、長い変数名などを含むすべてのテキストを保存して、後で完全に再現できるようにする必要があります。一方、ミニファイは不可逆的です。コードを縮小すると、コードからこの情報の多くが削除され、GZIPが保持する必要のある情報が少なくなります。

• 縮小は、不必要に空白を破棄し、構文上の理由で必要な場所にのみ空白を残します。
• 縮小はコメントを削除します。
• コードの縮小により、副作用のない識別子名が短い名前に置き換えられる場合があります。
• コードの最小化により、コードを簡単に「コンパイラー最適化」できる場合がありますが、これは実際にコードを解析することによってのみ可能です。
• CSSの縮小により、冗長なルールを削除したり、同じセレクターを持つルールを組み合わせたりできます。

あなたが正しい。

gzipを圧縮するよりも縮小するのは同じではありません（そうであれば、同じように呼ばれます）。たとえば、これをgzipすることは同じではありません。

var myIncrediblyLongNameForThisVariableThatDoesNothingButTakeUpSpace = null;

最終的に以下のようなものになるように縮小します：

var a = null;

もちろん、ほとんどの場合、最小化またはgzip圧縮よりも、FIRSTの次にGzipを最小化するのが最善の方法だと思いますが、コードによっては、単純化またはgzipするだけで両方を実行するよりも良い結果が得られる場合があります。

gzip-encodingが有利であるしきい値があります。一般的なルールは次のとおりです。ファイルが大きいほど、圧縮とgzipがうまく機能します。もちろん、最初に縮小してからgzipすることもできます。

しかし、長さが100バイト以下の小さなテキストでgzipとminifyを話している場合、「客観的な」比較は信頼できず、無意味です-ベンチマークの標準的な手段を確立するためのベースラインテキストが出ていない限り、 Lorem Ipsumタイプのようですが、JavaScriptまたはCSSで記述されています。

そこで、Fat-Free Minify（PHP）コードを使用して、jQueryとMooTools（非圧縮バージョン）の最新バージョンをベンチマークすることを提案します（空白とコメントを単純に取り除き、変数の短縮なし、baseXエンコードなし）。

以下に、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圧縮の強みは、コンテンツにどれだけ繰り返しがあるかです。したがって、gifyと比較した場合の縮小ではありません。彼らは違うことをします。そして、両方を使用することで、両方の長所を利用できます。

なぜ両方使用しないのですか？

テストは簡単です。CSSのテキストをテキストファイルに入れ、Linux上のgzipのようなアーカイバを使用してファイルを圧縮するだけです。

私はこれを行ったばかりで、最初のCSSのサイズは184バイトで、2番目のCSSは162バイトです。

したがって、あなたは正しいです。gzip圧縮されたファイルでも空白は重要ですが、この小さなテストからわかるように、本当に小さなファイルでは、圧縮ファイルのサイズが元のファイルのサイズよりも大きくなる場合があります。

これは、例のサイズが非常に小さいためです。大きなファイルの場合、gzipを実行すると小さなファイルになります。

Manglingについて言及している人はいないので、その結果を投稿します。

これは、縮小化とGzipにUflifyJSを使用して思いついた図です。約20 MBのファイルを約2.5 MBで連結し、コメントなどをすべて含めました。

連結ファイル2.5MB

uglify({
    mangle: false
})

マングリングなしで縮小：929kb

uglify({
    mangle: true
})

縮小および圧縮：617kb

これらのファイルを取得してgzipすると、それぞれ239kbと190kbになります。

これをテストする非常に単純な方法があります。空白のみで構成されるファイルと、本当に空の別のファイルを作成します。次に、両方をGzipしてサイズを比較します。空白が入っているファイルはもちろん大きくなります。

もちろん、レイアウトやその他の重要なものを保持し、不要なジャンク（空白、コメント、冗長なものなど）を削除する「人間の」不可逆圧縮は、可逆gZip圧縮よりも優れています。

たとえば、マークや関数名などは、意味を説明するために特定の長さになる可能性があります。これを1文字の長さの名前で置き換えると、多くのスペースを節約でき、ロスレス圧縮では不可能です。

ちなみに、CSSには、CSSコンプレッサーのようなツールがあり、損失の多い作業を行います。

ただし、「非可逆最適化」と可逆圧縮を組み合わせると、最良の結果が得られます。

もちろん、テストすることもできます-ファイルに書き込み、zlibで gzipしてください。「gzip」ユーティリティプログラムで試すこともできます。

あなたの質問に戻ってください-ソースの長さと圧縮された結果の間に明確な関係はありません。重要な点は「エントロピー」です（ソースの各要素はどのように異なるか）。

ですから、それはあなたのソースの状態に依存します。たとえば、多数の連続するスペース（ex、> 1000）は、少数（ex、<10）のスペースと同じサイズに圧縮される場合があります。

これは2つのファイルをgzipしたときの結果です

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

正解です。minify+ gzipを実行すると、バイト数が少なくなります。科学的な証拠はありませんが。

テストの方法がないのはなぜですか？

1つのファイルでコードを縮小し、別のファイルでは「縮小しない」ままにします。出力をgzipできるWebサーバー（Apacheの場合はmod_deflateなど）にアップロードし、Firefox用のFirebug拡張機能をインストールし、キャッシュをクリアして、両方のファイルにアクセスします。Firebugの[NET]タブには、転送されたデータの正確な量が含まれています。それらを比較すると、「実証的」な証拠があります。