Gzipとミニファイ

https://stackoverflow.com/questions/807119

03-07-2019
|

質問

先日、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の例を使用したさらなるテストです。ソースファイルは<！> quot; common.js <！> quot;です。元のファイルサイズは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の両方を行うことです。

他のヒント

<！> quot; real life <！> quot;を使用して、しばらく前に行ったテストの結果を次に示します。私のウェブサイトのCSSファイル。 CSS Optimiser は縮小に使用されます。 Ubuntuに付属する標準のLinuxアーカイブアプリがGzippingに使用されました。

オリジナル： 28,781 バイト
縮小： 22,242 バイト
Gzip圧縮： 6,969 バイト
Min + Gzip： 5,990 バイト

個人的な意見としては、Gzippingを最初に使用することです。これが明らかに最大の違いをもたらすからです。縮小に関しては、あなたの仕事の仕方に依存します。さらに編集するには、元のCSSファイルを保持する必要があります。変更のたびに縮小する必要がない場合は、それを実行します。

（注：他のソリューションがあります。たとえば、ファイルを提供し、ファイルシステムにキャッシュするときに、ミニファイアー<！> quot; on-demand <！> quotを介して実行するなどです。）

これをテストするときは注意してください。CSSのこれらの2つのスニペットは非常に小さいため、GZIP圧縮の恩恵を受けません。GZIPの小さなヘッダーだけを追加しても、得られる利益は失われます。実際には、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圧縮するよりも、最初にGzipを最小化するのが最善の方法だと思いますが、コードによっては、最小化またはgzip圧縮するだけで、両方を行うよりも良い結果が得られる場合があります。

gzipエンコードが有利なしきい値があります。一般的なルールは次のとおりです。ファイルが大きいほど、圧縮とgzipが勝ちます。もちろん、最初に縮小してからgzipで圧縮できます。

しかし、長さ100バイト以下の小さなテキストでgzipとミニファイについて話している場合、<！> quot; objective <！> quot;比較は信頼できず、無意味です-Lorem Ipsumタイプのように、JavascriptまたはCSSで記述された標準的なベンチマーク手段を確立するためのベースラインテキストを出さない限り。

ファットフリーミニファイ（PHP）コード（空白とコメントを単純に除去し、変数を短縮せず、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圧縮の強みは、コンテンツ内の反復回数にあります。そのため、gzipに対する縮小の問題ではありません。彼らは物事を異なって行います。そして、両方を使用することで両方の長所を活用できます。

両方を使用しない理由

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

これを実行したばかりですが、最初のcssのサイズは184バイトですそして、2番目は162バイトです。

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

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

マングリングに言及する人は誰もいなかったので、結果を投稿しています。

ここでは、ミニフィケーションとGzipにUflifyJSを使用して思いついたいくつかの図を示します。約20 MBのファイルがあり、約2.5 MBでコメントとすべてを連結しました。

連結ファイル2.5MB

uglify({
    mangle: false
})

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

uglify({
    mangle: true
})

縮小およびマングル：617kb

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

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

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

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

ところで、CSSには CSSコンプレッサーのようなツールがありますそれはあなたのために不可逆的な仕事をします。

ただし、<！> quot;損失のある最適化<！> quot;を組み合わせると、最良の結果が得られます。ロスレス圧縮。

もちろんテストできます-ファイルに書き込み、 zlib でgzipします。 <！> quot; gzip <！> quot;で試すこともできます。ユーティリティプログラム。

質問に戻ります-ソースの長さと圧縮結果との間に明確な関係はありません。キーポイントは「エントロピー」です（ソースの各要素の違い）。

それで、それはあなたのソースがどうであるかによります。たとえば、多数の連続したスペース（例：<！> gt; 1000）は、少数のスペース（例：<！> lt; 10）と同じサイズに圧縮できます。

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

bytes  File
45     min.txt
73     min.gz

72     normal.txt
81     normal.gz

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

どうしてテストする方法がないの？

1つのファイルでコードを最小化し、<！> quot; unminified <！> quot;のままにします。別の。出力をgzip圧縮できるWebサーバー（Apacheのmod_deflateなど）にアップロードし、firefoxのFirebug拡張機能をインストールし、キャッシュをクリアして両方のファイルにアクセスします。 Firebugの<！> quot; NET <！> quot;タブには転送されたデータの正確な量が含まれます。それらを比較すると、<！> quot; empirical <！> quot;証拠。

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow