[WP] Gzip圧縮 vs Brotli圧縮：2つの圧縮アルゴリズムの違い
WordPress CMSをはじめとするWebサイトを速くするには、サーバーでデータを圧縮する設定をしておくと便利です。こうすればWebサーバーとブラウザの間で送られるデータを速く読み込め、Webサイト全体も速くなります。これはWebサイトを運営する管理者がよく検討する要素の一つです。gzip圧縮は広く使われており、多くのWebサーバーでgzipから次第に Brotli 圧縮へ切り替える動きが広がっています。
1️⃣ 圧縮とは？
サイト URLにアクセスすると、ブラウザとサーバーの間で対話が始まります。このときブラウザはサーバーに、コンテンツの圧縮（Compression）を解除できるかどうかと、どの圧縮アルゴリズムを使うかという情報を伝えます。これはサーバーが圧縮したデータを送るとき、ブラウザが正しく解凍できるようにする役割を果たします。そのため圧縮アルゴリズムに対応したサーバーとブラウザを使えば、Webサイトの読み込み速度をさらに速くできます。
Webブラウザはサーバーに接続すると、gzip圧縮やBrotli圧縮のようなヘッダーを送ります。どちらかで圧縮されたデータがブラウザに届き、圧縮されたデータは圧縮されていないデータより速く読み込まれます。
Content-encoding: gzip
Content-encoding: br
Gzip圧縮の確認 
Brotli圧縮の確認
圧縮されるファイルは主にテキストです。 · HTML · CSS · JavaScript
2️⃣ Gzip圧縮とは？
Webホスティング会社でよく使われる一般的な圧縮アルゴリズムはGzipとBrotliです。Gzipは1992年にベータ版が作られ、1993年にバージョン1.0がリリースされました。一般に Gzipとは インターネットでデータを送るときに圧縮するための標準的な圧縮方法の一つです。この方法は初期の圧縮アルゴリズムであるDEFLATE圧縮をベースにしており、以前に開発されたUnixのファイル圧縮プログラムgzipから名前を取っています。
DEFLATE圧縮は、LZ77（Lempel-Ziv 1977）アルゴリズムとハフマン符号化を組み合わせた圧縮方式です。LZ77は重複するデータを探して一致する文字列を見つけ、その文字列をコードに置き換えることで圧縮します。ハフマン符号化は各文字の出現頻度を使って、最も短いビットコードを割り当てる方式で圧縮します。
GzipはDEFLATE圧縮方式でデータを圧縮し、HTTPのリクエストとレスポンスで‘Accept-Encoding: gzip’ヘッダーを使って、クライアントがGzip圧縮に対応している場合にだけ圧縮を行います。これによりデータを圧縮して、Webサイトの読み込み速度を上げられます。
3️⃣ Brotli圧縮とは？
Brotli圧縮は、2013年にGoogleのJyrki AlakuijalaとZoltán Szabadkaが開発しました。
Gzipはもともとファイルを圧縮するためのものでしたが、 Webでも使えるように変更されました。一方、Brotli圧縮は Webで使う目的で開発されました。そのため、Brotliを使えばWebサーバーがコンテンツをブラウザへ送る前に圧縮できます。ブラウザへストリーミングされる前に圧縮されるので、より優れた進んだ方式です。
Brotli圧縮は、GZIP圧縮と同じLZ77とハフマン符号化という2つの中核技術を使います。
4️⃣ Gzip圧縮vs Brotli圧縮
GzipはDEFLATE方式で、BrotliはLZ77とハフマン符号化にコンテキストモデリングを加えた独自形式でデータを圧縮（& 解凍）します。
- GzipはBrotliより圧縮速度が速いです。
- Brotliはウェブ専用に設計されました。
- Brotliはすべての圧縮レベルでより良い圧縮率（つまり、より小さい圧縮ファイル）を実現します。
- BrotliはGzipより、3種類のファイルの圧縮率がそれぞれHTMLで21%、CSSで17%、JavaScriptで14%優れています。
GzipよりBrotliを好むWebサーバーが増えつつあります。Brotliはストリームをすぐに圧縮するよう設計されているため、Gzipと比べてフロントエンド全体の解凍速度が最大64%速いとされています。
1996年5月に公開されたRFC 1952は、Gzip形式がDEFLATE圧縮方式を使い、データの破損を確認するCRC値を含むと説明しています。圧縮したデータの末尾には、元データのCRC-32値とサイズが記録されます。
2016年7月に公開されたRFC 7932は、BrotliがLZ77アルゴリズムとハフマン符号化を組み合わせて圧縮すると記しています。さらに圧縮前データの直前の2バイトをコンテキストとしてハフマン符号を選び、繰り返し文字列の代わりに122,784バイトの静的辞書にある単語を参照することもできます。
2つの形式はレスポンスヘッダーに[Content-Encoding: gzip]と[Content-Encoding: br]として表示されます。[br]の値はRFC 7932でHTTPのコンテンツコーディングとして登録されました。
| 項目 | Gzip | Brotli |
|---|---|---|
| 仕様書 | RFC 1952 · 1996年5月 | RFC 7932 · 2016年7月 |
| 圧縮方式 | DEFLATE（LZ77とハフマン符号化） | LZ77とハフマン符号化 · 直前の2バイトのコンテキスト · 静的辞書122,784バイト |
| レスポンスヘッダー | Content-Encoding: gzip | Content-Encoding: br |
5️⃣ Gzip圧縮とBrotli圧縮の実測：Nginx + Apacheサーバー
NginxとApacheを併用するWordPressサーバーで、同じ記事1本とWordPress標準のブロックCSSファイル、jQueryファイルのレスポンスを、リクエストヘッダーだけを変えて比較しました。[Accept-Encoding]にgzipだけを入れたリクエスト、brだけを入れたリクエスト、ヘッダーのないリクエストを同じサーバーからcurlで送りました。
for ae in gzip br ''; do echo == ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/hello-world/ | grep -i -E '^(content-encoding|size)'; done== gzip
content-encoding: gzip
size: 21390
== br
content-encoding: br
size: 20190
== none
size: 90833記事1本のHTMLは、gzipのリクエストで21,390バイト、brのリクエストで20,190バイトに圧縮され、ヘッダーのないリクエストには圧縮していない90,833バイトで応答しました。brのレスポンスはgzipより1,200バイト（5.6%）小さくなりました。
for f in wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do for ae in gzip br ''; do echo == ${f##*/} ${ae:-none}; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H Accept-Encoding:$ae https://example.com/$f | grep -i -E '^(content-encoding|size)'; done; done== style.min.css gzip
content-encoding: gzip
size: 19655
== style.min.css br
size: 140829
== style.min.css none
size: 140829
== jquery.min.js gzip
content-encoding: gzip
size: 30633
== jquery.min.js br
size: 87553
== jquery.min.js none
size: 87553gzipのリクエストでは、CSSファイルは19,655バイト、jQueryファイルは30,633バイトに圧縮されました。brだけをリクエストしたときやヘッダーがないときは、[Content-Encoding]ヘッダーなしで140,829バイトと87,553バイトの元ファイルをそのまま応答しました。
nginx -V 2>&1 | grep -c brotli0httpd -M 2>/dev/null | grep -E 'brotli|deflate' deflate_module (shared)
brotli_module (shared)CSSやJSのような静的ファイルはNginxが直接応答して圧縮し、この構成のNginxにはBrotliモジュールがないため、gzipでのみ圧縮します。
HTMLは、NginxがApacheに渡したリクエストにWordPressが応答し、Apacheが圧縮します。ApacheにはBrotliモジュールと、Gzip圧縮を担う[mod_deflate]モジュールの両方があります。
for f in hello-world/ wp-includes/css/dist/block-library/style.min.css wp-includes/js/jquery/jquery.min.js; do echo == $f; curl -s -o /dev/null -D - -w 'size: %{size_download}\n' -H 'Accept-Encoding: gzip, deflate, br, zstd' https://example.com/$f | grep -i -E '^(content-encoding|size)'; done== hello-world/
content-encoding: gzip
size: 21390
== wp-includes/css/dist/block-library/style.min.css
content-encoding: gzip
size: 19655
== wp-includes/js/jquery/jquery.min.js
content-encoding: gzip
size: 30633サーバーにBrotliモジュールがあっても、ブラウザがBrotliで圧縮されたレスポンスを受け取るとは限りません。Edge 155が送る値と同じ[gzip, deflate, br, zstd]でリクエストすると、ApacheもHTMLをgzipで圧縮し、3つのファイルすべてがgzipで応答しました。
brをgzipより前に置いたり、[br;q=1.0, gzip;q=0.5]のようにbrを優先すると示したりしても、HTMLはgzipで応答しました。Edgeで同じ記事と2つのファイルを開いたときも、すべてgzipで転送されました。
最初のバイトまでの時間は、リクエストの順番を入れ替えて40回ずつ測ったcurlの[time_starttransfer]値の中央値で、リクエストごとに新しく接続したためTLSの接続時間も含まれます。HTMLは圧縮していないレスポンスが22.7ms、gzipが26.3ms、brが26.5ms、ブラウザと同じリクエストが25.0msでした。CSSとJSは圧縮の有無にかかわらず18～21msでした。
GzipとBrotliの圧縮速度は直接測らず、公開資料で比較しました。RFC 7932は、Brotliがgzipプログラムよりかなり高い圧縮率で圧縮し、現在のLZMA実装よりはるかに速く解凍すると記しています。GoogleはBrotliのリポジトリで、Brotliはdeflateと速度が同程度でありながら、より密に圧縮すると説明しています。
2015年、CloudflareはHTMLとCSS、JavaScriptのファイル10,655個で2つの方式を試験しました。Brotliの最高品質の結果はzlibの最高品質より平均1.19倍小さかったものの、圧縮速度は毎秒0.5MBで、zlibレベル9の41.9MBより大幅に遅くなりました。Brotliのレベル4はzlibのレベル8と圧縮率が同程度で、全体の平均では少し速かったものの、64KBより小さいファイルだけを見ると1.48倍遅くなりました。
HTML、CSS、JavaScriptなどのファイル圧縮によるWebサイト最適化の流れを見てきました。Webサイトの速度を改善するには、ファイル圧縮と 画像最適化が欠かせない要素の一つだと言えます。
🔢 FAQ & おすすめコンテンツ
ℹ️ 提携について
当サイトのコンテンツにはアフィリエイトリンクが含まれています。訪問者がこのリンクを通じて商品やサービスを購入すると、当サイトは販売元から手数料を受け取ります。この過程において、購入者が支払う金額（イベント割引適用で金額が下がります↓）は上昇しません。掲載されている価格・割引・在庫情報は作成時点のものであり、実際とは異なる場合がありますので、ご購入前に販売元にて最終確認をお願いいたします。商品の選定および評価は独自の基準に基づいて行われており、手数料の支払いの有無は紹介順や評価内容に影響を与えません。