圧縮（Gzip、Brotli、Zstd）

TL;DR — 圧縮はHTML、CSS、JavaScriptなどのテキストファイルをインターネットへ送る前に小さくし、ブラウザーが受け取るバイト数を減らします（実際にボトルネックなら読み込みを速くできます）。代表的なのは、どこでも動くGzipと、通常はより小さくGoogleが推奨するBrotliです。削減率はファイルによって変わるため、特定の割合を保証として扱いません。PageSpeed Insightsで「テキスト圧縮を有効にする」と表示された場合の対策です。という指示です。」

圧縮とは何か

ページを読み込むと、ブラウザーはページを構成するすべてのファイルをダウンロードします。圧縮は、ファイルを転送中だけ小さくし、受信側でブラウザーに展開させる方法です。訪問者から見えるページの内容は変わらず、より速く届きます。

各リクエストで短いハンドシェイクが行われます。

1. ブラウザーが「展開できるもの」を示します。対応アルゴリズム（gzipやbrなど）を列挙した**Accept-Encoding**ヘッダーを送ります。
2. サーバーが1つを選び、それでファイルを圧縮し、使用した方式を示す**Content-Encoding**ヘッダーを返します。
3. ブラウザーが展開してページを表示します。を示します。」

以上です。ファイルごとに自動で行われ、サーバーまたはホスティング設定で一度有効にします。

知っておくべき2つ

• Gzip — 実績のある方式です。すべてのブラウザーと検索エンジンが対応する安全な既定値です。
• Brotli — Googleが開発した新しい方式で、通常はGzipよりテキストを少し小さくします。ブラウザーが対応していればGoogleはBrotliを使うよう述べており、非対応の場合はGzipをフォールバックにします。

**Zstandard（Zstd）**も見かけるようになります。展開は高速ですが、まだ普及初期で広く使われているわけではありません。

圧縮ではないもの

• ミニファイではありません。 ミニファイはコードから空白やコメントを除き、圧縮は転送用にバイトを再パックします。別の作業なので、まずミニファイしてから圧縮し、両方を行います。
• キャッシュではありません。 キャッシュはファイルを再送しなくて済むようコピーを保存し、圧縮は送信するときにファイルを小さくします（その側面はキャッシュを参照）。

圧縮するものと省くもの

テキストを圧縮します。HTML、CSS、JavaScript、JSON、SVG、XMLファイル（サイトマップを含む）が対象です。

すでに圧縮されているファイルは圧縮しません。JPG、PNG、GIF、大半の動画、WOFF2ウェブフォント、大半のPDFは小さくならず、再圧縮は手間を浪費します。Googleも2008年にこの点を明確にしています。

SEOに役立つか

間接的に役立ちます。圧縮自体はランキング要因ではありません。ただし、ファイルが小さくなると読み込みが速くなり、Core Web Vitalsに影響する速度へつながります。設定したことに得点が与えられるからではなく、サイトを速くするために有効にします。

GzipとBrotliの数値、Googlebotが対応する方式と根拠、PageSpeed監査の閾値、圧縮レベル、サーバーでの有効化と確認方法は、Advancedタブで扱います。

TL;DR — 圧縮はHTTPのコンテンツエンコーディングのネゴシエーションです。クライアントはAccept-Encoding（qの重みやidentityを含められます）を送り、サーバーはリクエストとリソースごとにContent-Encodingを返します。コーディングで変わるキャッシュ可能なレスポンスにはVary: Accept-Encodingが必要です。Brotliは同じテキストで通常Gzipを上回り（15–20%小さいとよく言われますが、内容・バージョン・レベルによります）、対応時はGoogleが推奨しています。Gzipは普遍的なフォールバック、Zstdは登録済みですが普遍的ではない方式です。Googleのクローラー文書はGooglebotのZstd対応を述べていません。Googlebotはgzip、deflate、Brotli（br）に対応します。圧縮はランキング要因でも、TTFB／LCPや検索改善を保証するものでもありません。転送サイズを減らし、実際のボトルネックならTTFB → LCPを助け、Googleの取得上限（2026年の「Inside Googlebot」によるHTML 2 MB）以内にページを収める助けになります。MIMEタイプと測定結果で圧縮対象を決め、拡張子で一括除外しません。BREACHのリスクは秘密と攻撃者が反映した内容を混ぜるレスポンスに限られ、サイト全体で圧縮を無効にする理由ではありません。静的／事前圧縮アセットは高いレベル、動的コンテンツは低〜中程度のレベルを使い、自分のトラフィックとCPUで検証します。サイトマッププロトコルはgzip圧縮サイトマップを明示的に許可しています。

圧縮の正確な意味

圧縮、正確にはHTTPコンテンツエンコーディングは、テキストレスポンスの本文をネットワークへ送る前に小さくし、クライアントが少ないバイトを受け取ってローカルで展開できるようにします。リクエストごとにネゴシエーションされます。GoogleのLighthouse文書が説明するように、ブラウザーは対応する方式をAccept-Encodingリクエストヘッダーで示します。典型的なヘッダーはAccept-Encoding: gzip, deflate, brです。サーバーは1つを選び、レスポンスのContent-Encodingヘッダーで選択を示します。 “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” (翻訳)「ブラウザーがリソースを要求すると、対応する圧縮アルゴリズムをAccept-Encodingリクエストヘッダーで示します。」

HTTP仕様（RFC 9110）に沿って、2つの境界を正確に分けます。コンテンツコーディングはレスポンス本文である表現データの変換であり、接続上を移動するメッセージに作用する転送コーディングとは異なります。このページの圧縮はContent-Encodingで示すコンテンツコーディングです。Accept-Encodingは単純な一覧ではなく、受け入れ可能な方式の優先順位をq値で示し、q=0で拒否も表せます。identityは「コーディングなし」を意味します。ネゴシエーションした方式で本文が変わるキャッシュ可能なレスポンス（同じURLのgzip版とBrotli版など）にはVary: Accept-Encodingが必要です。（mod_deflate）（Vary）

対象はHTML、CSS、JavaScript、JSON、SVG、XML（サイトマップを含む）などのテキストです。GzipとBrotliは大幅に小さくでき、GoogleのPageSpeed指針は「gzip圧縮で転送レスポンスを最大90%削減できる」とする上限を示しています。これは上限であり標準値ではありません。実際の削減量は冗長性、サイズ、既存のミニファイ、方式・辞書のバージョン、圧縮レベルに依存します。 “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” (翻訳)「gzip圧縮を有効にすると、転送レスポンスのサイズを最大90%削減できます。」

圧縮と混同してはいけないものが2つあります。

• ミニファイではありません。 ミニファイはソースから文字（空白やコメント）を除き、圧縮はそのバイトを転送用に再エンコードします。まずミニファイし、次に圧縮します。
• キャッシュではありません。 圧縮は転送中のバイトを小さくするエンコーディング、キャッシュはCache-Control、ETag、CDNによる保存と再利用です。両者は補完関係にあります。保存側はキャッシュを参照します。

このページはクリティカルレンダリングパスハブ配下の圧縮の詳しい解説です。ハブは広いクリティカルバイトのチェックリストで「テキストを圧縮する」を挙げています。このページでその項目を詳しく扱います。

GzipとBrotliとZstd

圧縮率

Brotliは一般にテキストで優れますが、特定の数値を普遍的なものとして扱いません。 GoogleのLighthouse文書は監査の削減量をGzipで計算し、Brotliならさらに削減できると明記しています。web.devのBrotli codelabには、非圧縮で225 KBだったmain.bundle.jsがGzipで約61,6 KB、Brotliで約53,1 KBになった例があります。そのファイルではBrotliが約14%小さくなりましたが、方向性を示すだけで保証ではありません。方式・ライブラリのバージョン、選んだレベル、内容の冗長性、既にミニファイ済みかで差が変わります。圧縮対象をベンチマークし、他サイトの割合をそのまま使いません。 “if Brotli is used, even more savings are possible.” (翻訳)「Brotliを使えば、さらに削減できる可能性があります。」 関連資料

Gzipは普遍的なフォールバックです。 どこでも対応しているため、Googleは安全網として推奨しています。主要ブラウザーはGzipに対応しますが、Brotliより効率が低いという位置付けです。 “Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” (翻訳)「BrotliのフォールバックとしてGZIPを使います。GZIPは主要なブラウザーすべてでサポートされますが、Brotliより効率が低い方式です。」

Zstdは登録された第3の方式ですが、安全な既定値ではありません。 IANAのHTTPコンテンツコーディング登録簿にはgzip、br、zstdがありますが、登録はクライアント、クローラー、オリジン、CDNの普遍的な対応を意味しません。リクエストが求めた方式だけを広告し、フォールバックを残します。HTTP相互運用ではRFC 9659がzstdデコーダーに最大8 MBまでのウィンドウ対応を求め、より大きなウィンドウをエンコーダーが要求することを禁じています。zstdと辞書方式のdczも別物です。Caddyなどには実装がありますが、Googleの現行クローラー文書はgzip、deflate、Brotliを列挙し、GooglebotのZstandard対応を述べていません。Zstdは対応するスタックとリクエストで有効にする候補として扱い、まだGzip／Brotliの置き換えにはしません。 Evidence for this claim gzip, br and zstd are registered HTTP content codings, but registration is not universal client, crawler, origin or CDN support; deploy only a coding advertised for the individual request and preserve a valid identity or fallback path. For HTTP interoperability, RFC 9659 requires zstd decoders to support windows through 8 MB and encoders not to require larger windows; this `zstd` coding is distinct from dictionary coding `dcz`. Scope: registry Confidence: high · Verified: 2026-07-16 HTTP Content Coding Registry （encode zstd gzip）

ブラウザーとクローラーの対応

現在のブラウザーではBrotli対応がほぼ普遍的ですが、常にそうだったわけではありません。GoogleのLighthouse文書は、2022年12月時点でiOSのSafariを除く主要ブラウザーが対応していたと記しています。この差が、Gzipフォールバックを残す理由です。 “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” (翻訳)「2022年12月時点では、iOSのSafariを除く主要ブラウザーすべてがBrotliをサポートしています。」

Googleは、クライアントがBrotliを受け取れる場合はBrotliを使うよう推奨しています。Brotliは他の方式よりリソースのファイルサイズを小さくできるためです。 “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” (翻訳)「ブラウザーがBrotli（br）に対応しているなら、他の圧縮アルゴリズムよりリソースのファイルサイズを削減できるため、Brotliを使うべきです。」

Gzipへフォールバックし続ける場合

BrotliとともにGzipを常に設定します。コンテンツエンコーディングはリクエストごとに交渉されるため、正しく設定したサーバーはbrを広告するクライアントにはBrotliを、それ以外にはGzipを自動的に提供します。どちらか1つを選ぶのではなく、両方を提供してハンドシェイクに任せます。

Google（とBing）はBrotliとGzipに対応するか

多くの圧縮記事が根拠なしに断言する問いです。ここではGoogle自身の発言を、日付のある3段階の流れで確認します。

2008年の「Googlebotとの最初のデート」記事

Googleは2008年から自らの声で圧縮を説明しています。Maile OhyeとJeremy LilleyのGooglebotとの最初のデート：ヘッダーと圧縮 は、主要な検索エンジンとウェブブラウザーが帯域を節約するためGzipに対応し、x-gzip（Gzipと同じ）、deflate（Googleも対応）、identity（なし）も見かけると説明します。同じ記事は、Flash、JPG、PNG、GIF、PDFなど多くの形式がすでに圧縮されており、再圧縮の利得が小さいことも説明しています。古い「outdated」表示のある記事ですが本文は公開され、現在の話題に直接関係します。

Gary Illyesによる2020年のBrotli確認

GooglebotのBrotli対応は公式文書に載る前に非公式に確認されました。2020年8月、GoogleのGary IllyesはGooglebotチームとの面会後、数週間前にGooglebotがBrotli圧縮に対応するか尋ねられ、対応すると述べました。Barry Schwartzが同日にSearch Engine Roundtable で報じています。これは現行のクローラー概要文書より約4年前で、担当者の確認が文書化に先行することを示します。

現行の公式クローラー文書

現在は明確に記載されています。GoogleのCrawler (User Agent) Overview は、Googleのクローラーとフェッチャーがgzip、deflate、Brotli（br）をサポートすると述べます。各Googleユーザーエージェントが対応するエンコーディングは各リクエストのAccept-Encodingヘッダーで広告され、例はAccept-Encoding: gzip, deflate, brです。私のAhrefsGooglebotガイド にも、Googlebotがgzip、deflate、Brotli（br）に対応すると記載しています。 “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” (翻訳)「Googleのクローラーとフェッチャーは、gzip、deflate、Brotli（br）をサポートします。」 “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” (翻訳)「各Googleユーザーエージェントが対応するコンテンツエンコーディングは、各リクエストのAccept-Encodingヘッダーで示されます。例：Accept-Encoding: gzip, deflate, br。」 “Googlebot supports gzip, deflate, and Brotli (br).” (翻訳)「Googlebotはgzip、deflate、Brotli（br）をサポートします。」

したがって系譜は、2008年のブログ記事 → 2020年のIllyes確認 → 現行のクローラー文書です。これは確立した情報であり、推測ではありません。

Bingの文書上の空白

ここでBingには正直な注記が必要です。通常のHTMLクロールでBingbotがどのコンテンツエンコーディングを交渉するかを示す詳細な公開文書はなく、Googleのクローラー概要ページに相当するものもありません。Bingが文書化している範囲は狭く、Content Submission APIがGzipに対応し、gzip圧縮サイトマップ（.xml.gz）を送信できます。HTTP圧縮は現代のクライアントがAccept-Encodingで交渉する標準機構なので、Bingbotが少なくともGzipを扱うと推測するのは合理的ですが、Bingの文書化された声明ではなくHTTPの仕組みからの推論として扱います。これは2つの検索エンジンの文書透明性の差であり、Bingbotの実際の挙動への批判ではありません。

圧縮がパフォーマンスとCore Web Vitalsに重要な理由

因果関係を正確に述べる

圧縮は直接のランキング要因ではありません。圧縮が作用する仕組みは、転送サイズが小さくなればダウンロード時間が短くなり、Time to First Byteと、その後のLargest Contentful Paintを助け、それらがCore Web Vitalsに含まれるというものです。ただし「助ける可能性がある」に留まります。データベースクエリ、レンダーブロッキングスクリプト、DNS／接続設定など別の箇所がボトルネックなら、すでに小さいレスポンスを圧縮しても改善しません。自分のボトルネックと実環境の結果を測定します。評価されるのは圧縮設定ではなく速度の結果です。関連項目はTime to First Byte、Largest Contentful Paint、Core Web Vitalsです。

GoogleのMartin Splittによる、未圧縮のページ重量で考えると誤解しやすいという説明があります。重要なのはディスク上の未圧縮サイズではなく、圧縮後に実際にネットワークを通る量です。未圧縮で10 MBに見えるページがネットワーク上では5〜6 MBになることもあります。このSplittの説明は一次記録ではなくSearch Engine Journalの報道を介したものなので、ここでは引用せず要約しています。

圧縮とクロール効率 — 過小評価される側面

圧縮は人間向けのページ速度だけではありません。Googleの取得上限以内に収める助けにもなります。2026年の「Inside Googlebot」更新（Gary Illyes）では、GooglebotがHTMLをURLあたりおよそ2 MB取得するとされ、旧来の15 MBから減っています。上限を超えた内容は拒否ではなく切り捨てられ、取得部分だけがインデックスへ渡されます。HTMLを圧縮することは重要な内容を予算内に残す手段であり、Core Web Vitalsだけでなくクロール効率の問題です。クロールも参照してください。

Lighthouse「テキスト圧縮を有効にする」監査 — 正確な閾値という指示です。」

PageSpeed Insights／Lighthouseの**「テキスト圧縮を有効にする」**監査には明確な発火条件があります。br、gzip、deflateのcontent-encodingを持たないテキストレスポンスを集め、Gzipで圧縮して削減量を推定します。Googleの文書によると、元のレスポンスが1,4 KiB未満、または圧縮による削減可能量が元サイズの10%未満なら、Lighthouseは結果でフラグを立てません。したがって約1,4 KiB未満の小さなファイルは、未圧縮でも警告対象になりません。 “Enable text compression” (翻訳)「「テキスト圧縮を有効にする」という指示です。」 “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” (翻訳)「レスポンスの元サイズが1.4KiB未満、または圧縮による削減可能量が元サイズの10%未満なら、Lighthouseは結果でそのレスポンスにフラグを立てません。」 “Document request latency” (翻訳)「ドキュメントリクエストのレイテンシ。」

正しく設定したサイトでも監査に失敗できる理由

GoogleのPageSpeed文書には、プロキシサーバーやウイルス対策ソフトがクライアントへのダウンロード時に圧縮を無効にできるとあります。圧縮チェッカーが「圧縮が有効でない」と報告しても、途中の機器がContent-Encodingヘッダーを除去した誤検知かもしれません。レポートやサーバーを疑う前に、クリーンなネットワーク経路からテストします。 “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” (翻訳)「プロキシサーバーやウイルス対策ソフトは、ファイルをクライアントへダウンロードするとき圧縮を無効にできます。」 “compression isn’t enabled” (翻訳)「圧縮が有効になっていません。」

静的圧縮と動的圧縮 — 実装上のトレードオフ

圧縮レベル

どちらの方式にも、CPU時間と圧縮率を交換する調整可能なレベルがあります。

• Gzip: レベル1–9。
• Brotli: レベル0（圧縮なし）から11（最大）まで。

高いレベルほど強く圧縮しますが、CPU時間を多く消費します。

CPUコスト — 静的と動的を分ける理由

圧縮は無料ではなくCPUを消費します。事前に構築したアセットとオンザフライで生成するコンテンツではコストの形が大きく異なります。正しい設定はどちらにも共通する1つの数字ではなく、内容の変更頻度、キャッシュ／CDNの圧縮バリアントの扱い、トラフィック量、実測値で決まります。

• 静的（事前圧縮／ビルド時）アセット — 安定した内容を事前に一度圧縮できます。nginxのgzip_staticやApacheのmod_deflateは、リクエストごとに再圧縮せず事前圧縮ファイルを選べます。CPUコストをビルド時に一度だけ払うので高いレベルを使えます。
• 動的（リクエストごとに生成）レスポンス — 最大レベルをリアルタイムで使うと全レスポンスに遅延が加わるため、低〜中程度から始めます（動的コンテンツではBrotli品質4程度が速度と率の出発点になることがあります）。ただし固定ルールではなく、自分のCPU余力とトラフィックでベンチマークします。

実務上の出発点は、静的なら高く、動的なら低〜中程度です。ただし自分の変更頻度、キャッシュ／CDNの挙動、トラフィック、変更前後の測定で確認し、記事の数字をそのまま使いません。

圧縮を有効にする方法

仕組みはどこでも同じです。サーバー（またはCDN／エッジ）を設定してテキストレスポンスを圧縮し、BrotliをGzipフォールバック付きで広告します。プラットフォーム別の方法は次のとおりです。

• Apache — mod_deflate（Brotliはmod_brotli）。GoogleのPageSpeed指針が直接案内しています。
• Nginx — 組み込みのngx_http_gzip_module（gzip on;とgzip_types）と、br用Brotliモジュール。
• IIS — 組み込みのHTTP Compression（静的・動的）。
• CDN／エッジ — Cloudflare、Fastlyなどは通常Brotli＋Gzipを切り替えで提供し、Caddyはencode zstd gzipを公開します。
• アプリフレームワーク — Node／Expressのcompressionミドルウェア。Next.js／Vercelと多くの現代的ホストは既定で圧縮します。

次に検証します。正確なコマンドはChecklistsレンズを参照してください。最速の確認は、curl -I -H "Accept-Encoding: br, gzip" https://example.com/を実行し、レスポンスのcontent-encodingヘッダーを確認することです。

圧縮してはいけないもの

JPG、PNG、GIF、大半の動画、WOFF2フォント、大半のPDFなど、すでに圧縮された形式を再圧縮しません。再びGzipやBrotliをかけると、わずかな、場合によっては負のサイズ変化のためにCPUを使います。これは例であり完全な規則ではありません。安全な一般則はテキスト形式などMIMEタイプで範囲を決め、可能なら特定レスポンスの実測出力を確認することです。 “may not benefit and can grow.” (翻訳)「効果がなく、ファイルが大きくなることもあります。」

圧縮が「対象にならない」普遍的な最小レスポンスサイズもありません。小さい、または密度の高い本文ではフレーミングやメタデータのオーバーヘッドが削減量を消すことがありますが、損益分岐点は方式、実装、レスポンスヘッダー、内容で変わります。Lighthouseの1,4 KiB／10%閾値は特定監査の抑制規則であり、一般的なサイズ下限ではありません。

圧縮とBREACH — 範囲を限定したリスクであり、サイト全体を無効にする理由ではない

圧縮を無効にするよう勧めるセキュリティ助言を見かけることがありますが、一般化しません。BREACH型のリスクは圧縮一般の性質ではなく、特定の攻撃形態です。レスポンスが圧縮され、CSRFトークンなどの秘密と攻撃者が操作した反映内容が同じ本文に混ざり、攻撃者が繰り返し圧縮レスポンスの長さを観測して秘密を1バイトずつ推測できる場合に成立します。Apacheのmod_deflate文書もこの組み合わせをBREACH固有のレビュー対象として示します。秘密と攻撃者入力を圧縮本文で組み合わせないなら典型的な攻撃は適用されません。サイト全体のテキスト圧縮を無効にせず、脆弱なレスポンスと文脈を修正します。

サイトマップの神話 — 圧縮は明示的に許可されている

重要な訂正です。**Sitemapsプロトコルはgzip圧縮サイトマップを明示的に許可しています。**サイトマップをgzip化できない、またはすべきでないという考えは誤りです。sitemaps.orgのプロトコル は帯域を減らすためのgzipサイトマップ（.xml.gz）を認め、両検索エンジンが受け入れ、Bingの送信ツールもgzipに対応します。注意点は、非圧縮サイトマップが50 000 URL／50 MBの上限を守ることだけです。大規模サイトマップを転送時にgzip化するのは問題ありません。

圧縮はウェブパフォーマンスのどこに位置するか

圧縮は関連する施策の1つです。クリティカルレンダリングパスがダウンロードする重要バイトを小さくし、TTFBとその後のLCPを下げ、PageSpeed Insights／Lighthouse監査の対象になります。エンコーディングと保存を分担するキャッシュや、より小さいブロッキングファイルを早く描画させるレンダーブロッキングリソースとも組み合わせます。広いツール群はウェブパフォーマンスツールを参照してください。

AI要約

Advanced版の要点をまとめます。

• 圧縮＝HTTPコンテンツエンコーディングで、HTTP転送コーディング（RFC 9110、§8.4）とは異なります。HTML、CSS、JS、JSON、SVG、XMLサイトマップを転送前に小さくし、リクエストごとに交渉します。クライアントはAccept-Encoding、サーバーはContent-Encodingを使い、方式で変わるキャッシュ可能レスポンスにはVary: Accept-Encoding（§12.5.5）が必要です。
• 3つの方式: Gzip（普遍的フォールバック）、Brotli（テキストで通常小さく、15–20%とよく言われるが固定値ではない）、Zstd（IANA登録とRFC 9659の対象だが普遍的ではなく、Googlebot対応は文書化されていない）。BrotliとGzipを併用します。
• Googlebotはgzip、deflate、Brotli（br）に対応します。現行文書、2020年のGary Illyes確認、2008年記事に根拠があります。Bingには同等のクローラー圧縮文書がありません。
• ランキング要因ではなく、速度も保証しません。 小さい転送サイズは実際のボトルネックならTTFB → LCP → Core Web Vitalsを助けますが、直接保証されるのはネットワークバイトの削減です。Googlebotの約2 MB取得上限を超えるHTMLは拒否でなく切り捨てられます。
• Lighthouseの監査はbr／gzip／deflateなしのテキストを対象にし、約1,4 KiB未満または削減量10%未満を省きます。これは監査固有の規則で、プロキシやウイルス対策はContent-Encodingを除去して誤検知を起こせます。
• レベル: Gzip 1–9、Brotli 0–11。静的／事前圧縮は高く、動的内容はCPUと遅延を考えて低〜中程度にし、自分のトラフィックで検証します。
• 拡張子で一括除外しません。 MIMEタイプと実測出力で決め、画像、動画、WOFF2、大半のPDFは通常再圧縮しません。
• BREACHの範囲は、秘密と攻撃者が反映した内容を混ぜ、長さを観測できる圧縮レスポンスに限られます。
• Vary: Accept-Encoding、二重圧縮、方式ごとのETag／Content-Length／range挙動を検証します。
• サイトマップの神話を訂正: Sitemapsプロトコルはgzipサイトマップ（.xml.gz）を明示的に許可します。という指示です。」（q）（identity）

公式文書

圧縮とコンテンツエンコーディングに関する一次資料です。

Google

• テキスト圧縮を有効化（Lighthouse） — 監査の閾値、Accept-Encodingの交渉、Brotli優先とGzipフォールバック。
• brotliでネットワークペイロードをミニファイ・圧縮（web.dev codelab） — Brotliレベル0–11と静的／動的のトレードオフ、前後比較。
• Compressionを有効化（PageSpeed Insights） — 最大90%という数字、サーバーモジュール、プロキシ／ウイルス対策による誤検知。
• Googleクローラー概要 — gzip、deflate、Brotli（br）の決定的な記載。
• Googlebotとの最初のデート（2008） — Gzipとdeflate、再圧縮の利得がない形式の説明。

標準／プロトコル

• RFC 9110 — HTTP Semantics — 表現データの変換としてのコンテンツコーディング、転送コーディングとの違い、qとidentity、方式別キャッシュのVary要件。
• RFC 9659 — HTTP Content CodingとしてのZstandard — zstdの8 MBウィンドウ要件とdczとの区別。
• IANA HTTP Content Coding Registry — 登録済み方式の権威ある一覧。
• Apache mod_deflate文書 — Vary、二重圧縮の回避、ETag、BREACHレビュー。
• Cloudflare — content compression — オリジン／エッジ変換、最小レスポンスサイズ、方式選択。
• nginx ngx_http_gzip_static_module — 事前圧縮ファイルの配信。
• Sitemapsプロトコル — gzipサイトマップと非圧縮サイズ上限。（Accept-Encoding）（zstd）（br）（Vary: Accept-Encoding）（DeflateAlterETag）

セキュリティ

• BREACH攻撃 — 原研究 — 秘密と攻撃者が反映した内容を混ぜ、繰り返し長さを測る圧縮レスポンスという前提。

Bing／Microsoft

• BingbotのHTMLクロールにおけるコンテンツエンコーディング対応を指定する専用文書はありません。BingのURL／サイトマップ送信ヘルプはgzipサイトマップとContent Submission APIのGzipを確認しています（Bing Webmaster Toolsヘルプ）。クローラー側の対応はHTTP標準からの推論であり、文書化された声明ではありません。

原文からの引用

Googleによる記録上の発言です。#:~:text=フラグメントを持つリンクは、元ページの引用箇所へ移動します。

**Google — Lighthouse「テキスト圧縮を有効にする」**という指示です。」

• “When a browser requests a resource, it will use the Accept-Encoding HTTP request header to indicate what compression algorithms it supports.” (翻訳)「ブラウザーがリソースを要求すると、対応する圧縮アルゴリズムをAccept-Encodingリクエストヘッダーで示します。」 引用へ移動
• “If the browser supports Brotli (br) you should use Brotli because it can reduce the file size of the resources more than the other compression algorithms.” (翻訳)「ブラウザーがBrotli（br）に対応しているなら、他の圧縮アルゴリズムよりリソースのファイルサイズを削減できるため、Brotliを使うべきです。」 引用へ移動
• “The potential savings that Lighthouse lists are the potential savings when the response is encoded with GZIP. If Brotli is used, even more savings are possible.” (翻訳)「Lighthouseが示す削減可能量は、レスポンスをGZIPでエンコードした場合の削減量です。Brotliを使えば、さらに削減できる可能性があります。」 引用へ移動
• “If the original size of a response is less than 1.4KiB, or if the potential compression savings is less than 10% of the original size, then Lighthouse does not flag that response in the results.” (翻訳)「レスポンスの元サイズが1.4KiB未満、または圧縮による削減可能量が元サイズの10%未満なら、Lighthouseは結果でそのレスポンスにフラグを立てません。」 引用へ移動
• “As of December 2022 Brotli is supported in all major browsers except Safari on iOS.” (翻訳)「2022年12月時点では、iOSのSafariを除く主要ブラウザーすべてがBrotliをサポートしています。」、“Use GZIP as a fallback to Brotli. GZIP is supported in all major browsers, but is less efficient than Brotli.” (翻訳)「BrotliのフォールバックとしてGZIPを使います。GZIPは主要なブラウザーすべてでサポートされますが、Brotliより効率が低い方式です。」 引用へ移動

Google — PageSpeed Insights「Compressionを有効にする」

• “Enabling gzip compression can reduce the size of the transferred response by up to 90%.” (翻訳)「gzip圧縮を有効にすると、転送レスポンスのサイズを最大90%削減できます。」 引用へ移動
• “Proxy servers and anti-virus software can disable compression when files are downloaded to a client machine.” (翻訳)「プロキシサーバーやウイルス対策ソフトは、ファイルをクライアントへダウンロードするとき圧縮を無効にできます。」 引用へ移動

Google — クローラー（ユーザーエージェント）の概要

• “Google’s crawlers and fetchers support the following content encodings (compressions): gzip, deflate, and Brotli (br).” (翻訳)「Googleのクローラーとフェッチャーは、gzip、deflate、Brotli（br）をサポートします。」 引用へ移動
• “The content encodings supported by each Google user agent is advertised in the Accept-Encoding header of each request they make. For example, Accept-Encoding: gzip, deflate, br.” (翻訳)「各Googleユーザーエージェントが対応するコンテンツエンコーディングは、各リクエストのAccept-Encodingヘッダーで示されます。例：Accept-Encoding: gzip, deflate, br。」 引用へ移動

Gary Illyes、Google — 2020年のBrotli確認

IllyesはGooglebotチームとの面会後、GooglebotがBrotli圧縮に対応すると確認しました。2020年8月にXへ投稿され、同日にBarry Schwartzが報じた内容です。ここは報道の要約であり、逐語引用ではありません。 関連資料

どの圧縮設定を使うべきか

「GzipかBrotliか」から始めず、何をどこで配信するかから考えます。実務ではほとんど常に両方を提供します。

Q1. サーバー／CDNはGzipフォールバック付きBrotliを提供できますか？

• はい（現代的なNginx／ApacheモジュールまたはCDNの切り替え）→ Brotli＋Gzipを有効にします。brを広告するクライアントにはBrotli、それ以外にはGzipが自動で選ばれます。これが既定の回答です。Q2へ進みます。
• いいえ（古いスタック、Brotliモジュールなし）→ まずGzipだけを有効にします。どこでも対応し、効果の大部分を得られます。Brotliを追加できるときに見直します。

Q2. アセットは静的（事前構築）ですか、それともリクエストごとに生成されますか？

• 静的（CSS／JSバンドル、事前構築HTML、サイトマップ）→ ビルド時に高いレベル（最大Gzip 9／Brotli 11）で事前圧縮し、自分のアセットでベンチマークします。CPUコストは一度だけ払い、毎回小さいファイルを返します。
• 動的（アプリ／CMSがリクエストごとに生成するHTML）→ 低〜中程度（Brotli約4を出発点として測定）で圧縮します。最大レベルは各レスポンスにリアルタイム遅延を加えるため、適切な値は固定ルールではなく、トラフィックとCPU余力で決めます。

Q3. ファイルはすでに圧縮されたバイナリですか？（JPG、PNG、GIF、動画、WOFF2、大半のPDF）

• はい → 圧縮しません。 小さくならずCPUを浪費し、少し大きくなることもあります。圧縮ルールをテキストMIMEタイプに限定します。
• いいえ（HTML、CSS、JS、JSON、SVG、XML）→ 圧縮します。

Q4. 有効にした後もPageSpeedレポートが「テキスト圧縮を有効にする」と表示します。

• フラグ対象ファイルが約1,4 KiB未満、または削減量が10%未満ですか？ → そもそもLighthouseはフラグを立てません。
• curl -I -H "Accept-Encoding: br, gzip"でcontent-encodingヘッダーが見えますか？ → サーバーは正常で、経路上のプロキシまたはウイルス対策がヘッダーを除去した可能性があります。クリーンなネットワークで再テストします。
• content-encodingがまったくありませんか？ → サーバーは実際に圧縮していません。MIMEタイプの範囲とモジュール設定を確認します。という指示です。」

圧縮の設定と検証 — チェックリスト

テキストが圧縮され、Brotliが優先され、二重圧縮がないことを確認するための手順です。

• Gzipフォールバック付きBrotli — サーバーがbrを広告し、非対応クライアントにはGzipを返す。
• テキストMIMEタイプに限定 — HTML、CSS、JS、JSON、SVG、XML。画像、動画、WOFF2、大半のPDFは除外する。
• 静的アセットを高いレベルで事前圧縮 — ビルド時に最大Gzip 9／Brotli 11まで、記事のコピーではなくベンチマークで決める。
• 動的レスポンスは低〜中程度 — CPUと遅延のバランスを自分のトラフィックで確認する。
• 方式で変わるキャッシュ可能レスポンスにVary: Accept-Encodingがある。
• プロキシ／CDN／オリジン間で二重圧縮せず、各経路のContent-Lengthが実際の本文と一致する。
• コマンドラインでcurl -I -H "Accept-Encoding: br, gzip" https://example.com/を実行し、content-encoding: brまたはgzipを確認する。
• DevToolsのNetworkで、テキストレスポンスのtransferredサイズがresourceサイズより十分小さい。
• PageSpeed Insights／Lighthouseで約1,4 KiB超のテキストに警告がない。
• curlがヘッダーを示すのにチェッカーが無効と報告する場合、プロキシ／ウイルス対策による誤検知を除外する。
• 大きなサイトマップをgzip（.xml.gz）で配信し、非圧縮ファイルが50 000 URL／50 MB以内。
• ミニファイも行う — 圧縮とミニファイは積み重なる。という指示です。」（content-encoding）

圧縮チートシート

3つの方式

圧縮レベル

圧縮するものと省くもの

早見事項

• GooglebotはAccept-Encodingで交渉された**gzip、deflate、Brotli（br）**に対応（Zstdは未確認）。
• Googleが示すGzipの削減上限は**最大約90%**だが、上限であり通常値ではない。
• Lighthouseは約1,4 KiB未満または削減可能量10%未満を省く。これは監査固有の抑制規則。
• 圧縮はGooglebotの約2 MB取得上限以内にHTMLを収める助けになり、超過時は拒否ではなく切り捨てられる。
• 方式で変わるキャッシュ可能レスポンスにはVary: Accept-Encodingが必要。
• BREACHは秘密と攻撃者反映内容を混ぜるレスポンスに限られ、サイト全体で無効化する理由ではない。
• Sitemapsプロトコルはgzip（.xml.gz）を許可する。
• curl -I -H "Accept-Encoding: br, gzip" <url>でcontent-encodingとvaryを確認する。という考え。」

圧縮の神話と誤り

繰り返し現れる、学び直す価値のあるものです。

• 「圧縮でランキングが上がる。」 公式資料も担当者も、圧縮をランキングシグナルとは述べていません。ページ速度／Core Web Vitalsへ入力する施策であり、単独の得点要因ではありません。速度のために有効にし、正確に説明します。
• 「GoogleはBrotliに対応しないのでGzipを使う。」 古い情報です。Googleのクロール基盤は少なくとも2020年から対応し、現行文書にも明記されています。
• 「画像、フォント、動画を圧縮すると速くなる。」 逆効果です。JPG、PNG、GIF、大半の動画、WOFF2はすでに圧縮済みで、再圧縮はCPUを使い、利得がなく時には大きくなります。テキストに限定します。
• 「有効にしたのにPageSpeedが圧縮オフと言うのでレポートが壊れている。」 必ずしもそうではありません。プロキシやウイルス対策が測定前にContent-Encodingを除去し、誤検知になることがあります。curlでクリーンな経路を確認します。
• 「圧縮とミニファイは同じ。」 違う段階です。ミニファイはソース文字を除き、圧縮は転送用にバイトを再エンコードします。両方行います。
• 「最大圧縮が常に最良。」 動的コンテンツでは過大な主張です。Gzip 9やBrotli 11はリクエストごとにCPUを使うため、静的／事前圧縮は高く、オンザフライは中程度にします。
• 「サイトマップをgzipできない／すべきでない。」 誤りです。Sitemapsプロトコルはgzipサイトマップ（.xml.gz）を明示的に許可します。非圧縮ファイルは50 000 URL／50 MB以内にします。

コマンドラインでネゴシエーション済み圧縮を確認する

macOS／Linuxで実行します。--compressedは対応方式を広告し、表示用に本文を展開します。ヘッダーにはネットワークを通った方式が残ります。

curl -sS --compressed -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: br' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: gzip' -D - -o /dev/null https://example.com/app.js
curl -sS -H 'Accept-Encoding: identity' -D - -o /dev/null https://example.com/app.js

キャッシュ可能なリソースでは、適切なContent-EncodingとVary: Accept-Encodingをレスポンスに含めます。共有キャッシュやCDNの背後にあるならヘッダーを明示的に確認します。欠落すると、あるクライアント用の方式を別の非対応クライアントへ配信できます。

Windows PowerShellでは各方式を要求してヘッダーを確認します。

$headers = @{ "Accept-Encoding" = "br, gzip" }
$r = Invoke-WebRequest -Uri "https://example.com/app.js" -Headers $headers
$r.Headers | Select-Object Content-Encoding, Vary, Content-Length

DevToolsで同一オリジンの未圧縮テキストリソースを見つける

ページの読み込み後にChrome DevTools Consoleへ貼り付けます。Resource Timingのサイズを候補の絞り込みに使いますが、キャッシュ済みやクロスオリジンの項目はサイズがないことがあるため、各レスポンスをNetworkパネルで確認します。

performance.getEntriesByType('resource')
  .filter((r) => r.transferSize > 0 && r.encodedBodySize === r.decodedBodySize)
  .map((r) => ({ url: r.name, bytes: r.transferSize }));

クローラーで圧縮ヘッダーを抽出する

レスポンスヘッダーを認識するカスタム抽出ワークフローでXPathを使い、クローラーがヘッダーを別に保存している場合だけHTMLマーカーを探します。通常のHTMLでは圧縮はHTTPヘッダーであり、DOMから抽出できません。この区別により、XPathだけで転送エンコーディングを証明できるという誤ったテストを防げます。

HTTP圧縮をテストするツール

• Chrome DevTools Networkパネル — Content-Encoding、転送サイズ、リソースタイプ、CDN／キャッシュによるレスポンス変更を確認します。
• curl --compressed — ブラウザーUIに頼らず、実際のネゴシエーションとBrotli、Gzip、identityのレスポンスを比較します。
• PageSpeed Insights／Lighthouse — 記事の「テキスト圧縮を有効にする」監査を発火するほどバイトを削減できるテキストを示します。
• WebPageTest — 一貫した場所、ブラウザー、ネットワーク条件で転送サイズとリクエストウォーターフォールを比較します。
• CDN／サーバー設定とログ — 静的と動的リソースで選ばれた方式と圧縮レベルを確認します。という指示です。」

圧縮が正しく設定されていることを証明する

エンコーディングネゴシエーションテスト

実行: テキストリソースをAccept-Encoding: br、gzip、identityで個別に要求します。期待: 対応する要求には対応するContent-Encodingが返り、identityは展開可能で、バリアントに適切なVaryが付きます。失敗の解釈: 交渉、キャッシュの変化、オリジン／CDN設定が誤っています。監視: 伝播直後。ロールバック: 本文の破損または方式の誤配信。

リソース範囲テスト

実行: HTML、CSS、JS、JSON／SVG／XMLと、圧縮済みの画像、動画、フォントをNetworkパネルでサンプリングします。期待: テキストは圧縮され、利得のない形式は再圧縮されません。失敗の解釈: MIMEタイプの許可リストが不完全または広すぎます。監視: 直後。ロールバック: 転送サイズ増加、オリジンCPU過多、アセット破損。

パフォーマンス回帰テスト

実行: 動的圧縮を有効にする前後で、再現可能なWebPageTest／LighthouseとサーバーCPUを比較します。期待: テキスト転送バイトが減り、TTFBやエラーに一貫した悪化がないこと。失敗の解釈: 選んだ方式／レベルのCPUコストが高すぎるか、圧縮層が誤っています。監視: ラボでは直ちに、本番では代表的な負荷で確認。ロールバック: 持続的遅延、CPU飽和、エラー増加。

キャッシュバリアント（Vary）テスト

実行: 異なるクライアントへ異なる方式で返すキャッシュ可能レスポンスを、同じCDN／キャッシュ経路でbr、gzip、identityの順に要求します。期待: 各バリアントが要求された方式で正しく返り、キャッシュキーに交渉方式を含めるVary: Accept-Encodingを持ちます（RFC 9110、§12.5.5）。失敗の解釈: 共有キャッシュが1つの方式を保存し、展開できないクライアントへ返しています。監視: CDN／キャッシュ層を変更した直後。ロールバック: 非対応方式の本文を受け取るクライアント、またはキャッシュキー拡大によるヒット率崩壊。（Accept-Encoding: br）

二重変換と古いメタデータのテスト

実行: オリジンとエッジのヘッダーを比較するなど、すべてのプロキシ／CDN／オリジンを経路追跡し、圧縮が正確に一度だけ適用されることを確認します。期待: 最終Content-Encodingが1つの方式を示し、Content-Lengthが送信本文と一致し、変換前のidentity長が残りません。失敗の解釈: 中間層が本文を展開・再圧縮した、または圧縮済み本文を再圧縮したのに長さ／整合性メタデータを更新していません。監視: CDN、リバースプロキシ、エッジ変換を導入・変更した後。ロールバック: ダウンロード破損、Content-Length不一致、二重圧縮。（mod_deflate）

バリデーターとrangeリクエストのテスト

実行: 同じリソースをidentity、gzip、brで要求し、各方式のETag、Content-Length、range要求の挙動を比較します。期待: 各表現が別物として扱われ、固有のETag（または文書化された共有ポリシー）、方式ごとの正しいContent-Length、選択された表現に適用されたrangeの意味を持ちます。失敗の解釈: 単一の表現を前提にバリデーターや部分コンテンツ処理を構築し、条件付き要求や圧縮バリアントのバイト範囲を壊しています。監視: 直後と圧縮設定／CDNキャッシュ変更後。ロールバック: 圧縮バリアントで条件付き要求またはrange要求が誤った本文や破損本文を返す。（Range）（If-None-Match）

自分で確認する: 圧縮

HTTPテキスト圧縮の仕組みとGoogleが対応する方式についての5つの短い質問です。各問に答えてから確認します。

変更履歴