gzip と HTTP/3 とは？Web ページ読み込みパフォーマンスで最初に改善すべきこと

gzip は、Web ページのテキストファイルを圧縮して送信するデータ量を減らす方法です。一方、HTTP/3 は、HTTP を QUIC 上で配信することで、複数リクエストの処理方法とパケットロスへの対処方法を変えるプロトコルです。どちらもページ読み込みに役立ちますが、解決する問題は同じではありません。「gzip と HTTP/3 のどちらが速いか」と問うより、まず現在のページのボトルネックがどこにあるのか、つまり転送バイト数、ネットワークロス、サーバーレスポンス、画像、レンダリング、JavaScript のどれなのかを確認する方が正確です。www.rfc-editor.org↗datatracker.ietf.org↗

実務で特に多い誤解の一つは、HTTP/3 を有効化すれば Web サイト全体が自動的に速くなるというものです。HTTP/3 は重要な基盤改善になり得ますが、ファーストビューの画像が過度に大きい問題、レンダリングをブロックする CSS や JavaScript、遅いサーバーレスポンスの解決策にはなりません。逆に、サイトがテキストレスポンスをまったく圧縮していないなら、gzip や Brotli を有効化することで、比較的小さな設定変更で転送量を目に見えて減らせます。web.dev↗developer.mozilla.org↗

gzip とは正確には何ですか？

gzip は、HTTP で広く使われている**コンテンツエンコーディング（Content-Encoding）**です。サーバーは元の HTML、CSS、JavaScript、JSON、SVG などを gzip 形式で圧縮してから送信し、ブラウザはそれを展開して元のコンテンツとして利用します。HTTP Semantics 仕様では、gzip は LZ77 系の圧縮と 32 ビット CRC を使用するコンテンツコーディングとして定義されています。www.rfc-editor.org↗www.rfc-editor.org↗

重要なのは、ファイルの論理的な種類が変わらない点です。たとえばサーバーが app.js を gzip で配信しても、最終的にブラウザが実行するのは同じ JavaScript です。変わるのはネットワーク上を流れるバイト数です。ファイルが小さくなれば、帯域幅が限られた環境でのダウンロード時間を短縮でき、ユーザーのモバイルデータ通信量も減らせます。www.rfc-editor.org↗developer.chrome.com↗

ブラウザとサーバーは圧縮方式をどのように選びますか？

ブラウザは Accept-Encoding リクエストヘッダーを使用して、デコード可能な圧縮形式を示します。サーバーはその一覧と優先度に基づいて適切な表現を選び、レスポンスに Content-Encoding: gzip や Content-Encoding: br などのヘッダーを追加します。br は Brotli を意味します。www.rfc-editor.org↗developer.mozilla.org↗

サーバーまたは CDN が圧縮方式によって同じ URL に異なるレスポンスを返す場合、キャッシュがそれらを区別できるように Vary: Accept-Encoding を送信するのが一般的です。そうしなければ、あるクライアント向けに保存された圧縮表現が、条件の異なるリクエストに不適切に再利用される可能性があります。www.rfc-editor.org↗

概念的な流れは次のとおりです。

1. ブラウザが Accept-Encoding: br, gzip のようにサポートする形式を通知します。
2. サーバーまたは CDN が、ファイルの Brotli 版、gzip 版、非圧縮版のいずれかを選びます。
3. レスポンスボディとともに Content-Encoding で選択した形式を示します。
4. ブラウザは受信中または受信後にレスポンスを展開し、HTML の解析、CSS の適用、JavaScript の実行を続けます。

gzip はこの過程の転送時間を短縮できますが、ブラウザが JavaScript を解析・実行する時間をなくすものではありません。圧縮はパフォーマンスの一要素であり、すべての遅延原因を解決する手段ではありません。developer.chrome.com↗web.dev↗

gzip の効果が得られるファイルは？

gzip は、繰り返し出現する文字列や構造が多いテキストに特に適しています。HTML タグ、CSS セレクター、JavaScript の識別子や構文、JSON のフィールド名など、繰り返しが多いデータは、圧縮後に転送サイズを大幅に小さくできる場合があります。一般的な Web パフォーマンスのガイダンスでも、テキストリソースには圧縮を適用し、すでに圧縮されているアセットは対象から除外することが推奨されています。developer.mozilla.org↗web.dev↗

JPEG、WebP、AVIF、動画、音声、圧縮アーカイブのように、形式自体がすでに圧縮を行うものに gzip を重ねても、効果はほとんど得られない場合があります。小さなファイルについても同様です。web.dev は、およそ 1 KiB 未満のリソースでは圧縮効率が悪くなる、または意味のある削減効果が得られない可能性があると説明しています。developer.mozilla.org↗web.dev↗

ここで重要なのは、転送サイズと元のサイズを区別することです。開発者ツールの Network パネルでは、圧縮後のダウンロードサイズと非圧縮サイズを比較できます。また、Content-Encoding レスポンスヘッダーを確認すれば、圧縮が実際に適用されたかどうかを検証できます。developer.chrome.com↗

gzip と Brotli の違いは？

Brotli は gzip の後継ではなく、HTTP コンテンツ圧縮で gzip と並んで選択できる別のアルゴリズムです。現在の Web では、テキストアセットでは Brotli を優先しつつ、Brotli を使えないクライアント向けに gzip も提供する構成が一般的です。ブラウザが Accept-Encoding を送信し、サーバーがその結果をネゴシエーションするため、クライアントによって同じ URL に異なる圧縮表現を送ることができます。developer.mozilla.org↗developer.mozilla.org↗

一般に、Brotli は Web テキストで gzip より小さな結果を生成できる場合があります。ただし、それがページ全体の体感速度の比例した改善を常に意味するわけではありません。削減できるバイト数が小さい場合や、ボトルネックが画像、サーバー処理、JavaScript 実行にある場合は、gzip から Brotli への切り替え効果は限定的です。動的圧縮を行うサーバーでは、圧縮率を高める設定が CPU 使用量とレスポンス遅延を増やすこともあります。そのため、静的アセットはビルド時または CDN の段階で事前圧縮し、動的レスポンスは実際の負荷に基づいて調整するべきです。web.dev↗web.dev↗

つまり、選定基準は「Brotli は常に優れている」ではなく、次のように考える方が適切です。

• テキストアセットが大きく、初回訪問者が多い場合は、Brotli と gzip の両方の配信を検討します。
• CDN がすでに適切な圧縮を提供している場合、アプリケーションで同じコンテンツを再圧縮しません。
• サーバー CPU に制約のある動的サービスでは、圧縮レベルと TTFB のバランスを計測します。
• 画像や動画がページの大きな割合を占める場合は、テキスト圧縮より先にメディア最適化が必要なことがあります。

HTTP/3 は何を変えますか？

HTTP/3 は、HTTP のリクエスト・レスポンスの意味論を維持したまま、トランスポート基盤を TCP から QUIC に置き換える標準です。QUIC は UDP 上で動作しますが、単に HTTP を UDP で送る仕組みではありません。接続確立、暗号化、信頼性、輻輳制御、多重化されたストリームなどの機能を提供し、HTTP/3 はこれらの機能を使って HTTP メッセージを配信します。datatracker.ietf.org↗developer.mozilla.org↗

HTTP/1.1 には単一接続上でリクエストを処理する際の大きな制約があり、複数の TCP 接続を並列に使う方法が広く採用されました。HTTP/2 は、1 本の TCP 接続上で複数リクエストを多重化することでこれを改善しました。しかし TCP は受信データの順序どおりの配信を保証するため、接続でパケットロスが起きると、そのロスが回復するまで後続データを順番にアプリケーションへ渡せません。HTTP/2 では、この TCP レベルの遅延が複数の HTTP ストリームに影響する可能性があります。datatracker.ietf.org↗www.rfc-editor.org↗

HTTP/3 の QUIC は、ストリーム単位で信頼性のある順序どおりの配信を管理します。そのため、あるストリームでデータが失われても、無関係なストリームまで必ず停止する必要はありません。RFC 9000 は、パケットが失われた場合、再送待ちでブロックされるのはそのパケット内のデータを含むストリームだけであり、他のストリームは継続できると説明しています。www.rfc-editor.org↗

「ヘッドオブラインブロッキングをなくす」という表現はどの程度正確ですか？

HTTP/3 が主に対処するのは、接続全体にまたがるトランスポート層のヘッドオブラインブロッキングです。これを、すべての待ち時間がなくなる意味と解釈するのは不正確です。

まず、単一ストリーム内では依然として順序が重要です。HTML ドキュメントの本文や 1 枚の大きな画像など、同じストリームの先行部分が失われた場合、必要な順序が復元されるまで後続データを完全には利用できません。次に、複数ストリームのデータが 1 つの QUIC パケットに含まれていた場合、そのパケットの消失により、それら複数のストリームが同時に遅延することがあります。www.rfc-editor.org↗

したがって HTTP/3 の利点は、パケットロスや順序入れ替わりが発生するネットワークで特に現れやすいといえます。反対に、有線で低遅延かつロスの少ない接続で小さなページを表示する場合、HTTP/2 との差は小さいことも、測定条件により変動することもあります。HTTP/3 はバイト数を魔法のように減らす技術ではなく、転送中の待ち時間が広がる範囲を抑えるアーキテクチャだからです。datatracker.ietf.org↗www.rfc-editor.org↗

HTTP/3 の QPACK は gzip とどう違いますか？

HTTP/3 には QPACK というヘッダー圧縮機構が含まれます。そのため HTTP/3 に gzip が含まれていると誤解しやすいのですが、対象は異なります。QPACK は、Cookie、Content-Type、Cache-Control など、HTTP リクエストとレスポンスのヘッダーフィールドを効率的に表現するために設計されています。gzip と Brotli は、HTML、CSS、JavaScript などのレスポンスボディを圧縮するコンテンツエンコーディングです。datatracker.ietf.org↗www.rfc-editor.org↗

HTTP/2 の HPACK は、ヘッダー圧縮状態が順序どおりに配信されるという前提に依存していますが、その前提を QUIC の独立したストリームアーキテクチャにそのまま適用することは困難です。QPACK は、動的テーブルの状態を管理するために独立した単方向ストリームを使用し、実装が圧縮効率とヘッダーブロッキングのリスクのバランスを取れるようにします。datatracker.ietf.org↗datatracker.ietf.org↗

実際のページパフォーマンスの観点では、それぞれの役割を次のように捉えると便利です。

• gzip と Brotli: テキストボディの転送量を減らします。
• QPACK: リクエストおよびレスポンスヘッダーの送信効率を改善します。
• HTTP/3 と QUIC: 多数のリクエストやロス条件による転送遅延が、他のリクエストへ広がる範囲を抑えます。
• キャッシュ: すでに受信済みのリソースを再転送しないようにします。
• 画像とコードの最適化: そもそもダウンロード・処理すべき作業量を減らします。

これらは単一選択で競合するものではなく、異なるボトルネックに対する補完的なアプローチです。

体感上の Web ページ速度では、より大きなボトルネックは何ですか？

ユーザーが感じる読み込み速度は単一の数値ではありません。サーバーが最初の 1 バイトを送るまでの時間、ファーストビューの主要コンテンツが表示されるまでの時間、ボタンや入力欄が応答するまでの時間は、それぞれ異なる原因によって遅れる可能性があります。特に LCP（Largest Contentful Paint）は、ビューポート内で最大の画像、テキストブロック、または動画が描画された時点を表すため、初期ページ体験の評価に役立ちます。web.dev↗

LCP が遅いからといって、常にネットワーク圧縮が原因とは限りません。web.dev は、LCP 診断時に TTFB、リソース読み込み遅延、リソース読み込み時間、要素のレンダリング遅延を分けて考えることを推奨しています。たとえば画像がすばやくダウンロードされても、大きな CSS がレンダリングをブロックしたり、長い JavaScript タスクでメインスレッドが忙しすぎて画像を表示できなかったりすることがあります。web.dev↗

ファーストビュー画像がボトルネックの場合

最大のファーストビュー要素は、商品詳細ページの大きな商品写真、ニュースホームページのリード画像、旅行ページのバナーなど、画像であることがよくあります。この状況では、gzip を有効にしても JPEG、WebP、AVIF ファイルそのものへの効果はほとんどありません。より効果的なのは、表示寸法に合わせた画像を配信し、適切な最新形式を使用し、LCP 画像を loading="lazy" で遅延させないことです。必要に応じて fetchpriority="high" を使って優先度ヒントを与えることもできますが、多くの画像に無差別に高優先度を付けると、かえって競合を生む可能性があります。web.dev↗web.dev↗

CSS と JavaScript がボトルネックの場合

CSS は、スタイルなしのコンテンツ表示を防ぐため、レンダリングをブロックする性質があります。しかし、過度に大きい CSS、初期表示に不要な CSS、同期的に読み込まれるスクリプトは、主要コンテンツの表示を遅らせます。転送が完了した後も、大きな JavaScript バンドルは解析、コンパイル、実行のためにブラウザのメインスレッドを使うため、gzip でダウンロードサイズだけを減らしても十分ではない場合があります。developer.chrome.com↗web.dev↗

したがって、JavaScript のパフォーマンスは圧縮と分けて確認するべきです。候補には、未使用コードの削除、初期表示に不要な機能の遅延読み込み、長時間タスクの分割、可能な場合にはサーバーレンダリングやプリレンダリングの使用などがあります。これにより初期 HTML が中核コンテンツと、発見すべきリソースを公開できます。ただし、サーバーレンダリングはサーバー処理時間を増やして TTFB に影響する場合もあるため、アーキテクチャ変更は計測して評価する必要があります。web.dev↗

サーバーレスポンスとキャッシュがボトルネックの場合

TTFB が長い場合、ブラウザは HTML を受信するまで後続リソースを発見しにくくなります。よくある原因には、距離の離れた場所にあるサーバー、長時間のデータベース処理やパーソナライズ、不要なリダイレクト、活用されていないキャッシュ機会があります。この状況で HTTP/3 は転送段階の一部を改善できますが、サーバーが最初のレスポンスを生成するのに必要な時間を直接短縮するものではありません。web.dev↗

キャッシュは、他のパフォーマンス改善とは性質が異なります。gzip は同じデータをより小さな形式で送信し、HTTP/3 はデータを配信する接続特性を変え、キャッシュは条件を満たす再訪問時にデータ自体の再送を防ぎます。再訪問ユーザーの割合が高いサービスでは、適切なキャッシュポリシーが圧縮アルゴリズムの変更より大きな体感差を生むことがあります。ただし、HTML のように頻繁に変わるレスポンスや、ユーザーごとに内容が異なるレスポンスのキャッシュ戦略は、より慎重に設計する必要があります。www.rfc-editor.org↗developer.chrome.com↗

体感への影響別に見たパフォーマンス改善の実践的な優先順位は？

すべてのサイトに当てはまる固定順位はありません。ページ構成、初回訪問者と再訪問者の比率、ユーザーのネットワーク、サーバーの所在地、既存設定により結果は異なります。それでも、主なボトルネックが残っている一般的なコンテンツ、コマース、サービスページでは、次の順序で調査するのが実践的です。

1. ファーストビューの中核コンテンツを遅らせている要因を特定します。 まず LCP 画像のサイズ、発見タイミング、優先度、レンダリングをブロックする CSS、同期 JavaScript、不要なクライアントサイドレンダリングを確認します。web.dev↗
2. サーバーレスポンス時間とキャッシュを見直します。 TTFB、リダイレクト、CDN 配置、静的アセットのキャッシュ、バックエンド処理の遅延を確認します。web.dev↗www.rfc-editor.org↗
3. HTML、CSS、JavaScript、JSON のテキスト圧縮を確認します。 非圧縮であれば、gzip または Brotli の適用は高い優先度です。すでに適切に圧縮されているなら、同じ領域での追加効果は限定的な場合があります。developer.mozilla.org↗developer.chrome.com↗
4. 総転送量を減らし、リクエスト構成を最適化します。 大きな画像、スクリプト、サードパーティリソースを整理し、実際に必要になるまでリクエストを遅らせます。ネットワークペイロードが大きいほど、読み込み時間が長くなることと関連します。developer.chrome.com↗developer.chrome.com↗
5. HTTP/3 を提供し、HTTP/2 フォールバックを維持したうえで、実トラフィックで検証します。 特にモバイル、高遅延、パケットロスのある環境、および同時リクエストの多いページで、変更前後の結果を比較します。datatracker.ietf.org↗www.rfc-editor.org↗

この順位には重要な例外があります。アプリケーションに 1 MB を超える非圧縮テキストレスポンスがある場合、手順 3 の gzip または Brotli 適用が短期的に最大の改善になるかもしれません。逆に、リード画像が数 MB あり、テキストがすでに Brotli で圧縮されているなら、画像最適化が優先されます。サーバーが HTML を生成するまでに数秒かかる場合は、HTTP/3 より先にバックエンドとキャッシュの改善が必要です。developer.mozilla.org↗web.dev↗developer.chrome.com↗

gzip と HTTP/3 だけを比較する場合

この 2 つの技術だけから選ぶなら、判断は比較的明確です。

• テキストが非圧縮の場合: 通常は gzip または Brotli を先に導入します。送信するデータ量を減らすため、サポートされるあらゆる接続で効果が期待できます。
• 圧縮がすでに正しく機能している場合: HTTP/3 の相対的な価値が高まります。ただし実際の改善度は、ネットワーク品質とリクエスト構造に左右されます。
• 画像・動画中心のページの場合: gzip も HTTP/3 も、単独ではより大きな問題を解決できない可能性が高いです。先にメディア最適化を行います。
• 大規模な JavaScript アプリケーションの場合: gzip は出発点にすぎません。継続的な体感改善には、転送後の実行コストも調べる必要があります。
• 再訪問が多いサービスの場合: 圧縮方式の変更より、キャッシュヒット率の方が大きな変数になる可能性があります。

したがって、「gzip は常に HTTP/3 より先」も、「HTTP/3 は新しいので常に先」も正確ではありません。より正確には、非圧縮テキストではコンテンツ圧縮がベースラインの優先事項であり、HTTP/3 はトランスポート条件とリクエストパターンに応じて追加の効果をもたらし得る基盤最適化です。

HTTP/3 導入時に考慮すべき制約は？

HTTP/3 を提供するには、サーバー、CDN、ロードバランサー、ファイアウォール、オブザーバビリティツールが、QUIC と UDP ベースのトラフィックを適切に扱える必要があります。一部のクライアントや通信経路では HTTP/3 を利用できない可能性があるため、HTTP/2 や HTTP/1.1 も提供する段階的な展開が一般に適しています。HTTP/3 標準は QUIC に基づいており、クライアントが HTTP/3 サーバーを発見し、その後 QUIC 接続を確立するプロセスを定義しています。datatracker.ietf.org↗

運用面では、プロトコル切り替えだけで成功を判断しないことが重要です。HTTP/3 接続の割合、失敗・再試行率、TTFB、LCP、エラー率、CPU 使用量をあわせて監視します。特に CDN やプロキシがオリジンの前段にある場合、オリジンサーバーから見えるプロトコルと、エンドユーザーのブラウザが実際に使ったプロトコルは異なることがあるため、クライアント側の観測も含めるべきです。developer.chrome.com↗developer.chrome.com↗

圧縮にはセキュリティ上の考慮点がありますか？

はい。HTTPS を使用していても、攻撃者が制御できる入力と秘密値が同じ圧縮コンテキストで圧縮される場合、攻撃者は暗号文長の違いを観測して秘密を推測できる可能性があります。HTTP Semantics と HTTP/3 の仕様は、機密データと攻撃者制御データを一緒に圧縮する状況に注意を促し、機密データの圧縮を無効化すること、または圧縮コンテキストを分離することを最も信頼できる緩和策として挙げています。www.rfc-editor.org↗www.rfc-editor.org↗

これは、すべての gzip レスポンスが危険という意味ではありません。重要なのは、反映されたユーザー入力、認証に関連する秘密、攻撃者が繰り返しリクエストを行いレスポンスサイズを観測できる条件が、すべて同時に存在するかどうかです。ログイン、決済、アカウント復旧のような機密性の高いフローには、一般的な静的アセットと同じ圧縮ポリシーを機械的に適用すべきではありません。セキュリティ設計とあわせて確認する必要があります。www.rfc-editor.org↗datatracker.ietf.org↗

自分のサイトでは何を計測すべきですか？

単一のラボスコアよりも、実ユーザー体験を通じてパフォーマンス改善を検証する方が安全です。Lighthouse は潜在的な問題をすばやく特定するのに役立ちますが、多様なネットワーク、デバイス、キャッシュ状態、地域にいるすべての実ユーザーを表すものではありません。開発者ツールとリアルユーザーモニタリングを併用すると、仮説と結果を分けやすくなります。developer.chrome.com↗developer.chrome.com↗

次の順序でパフォーマンスを確認できます。

1. 現在の転送状態を確認します。 Network パネルで、主要な HTML、CSS、JS、JSON レスポンスの Content-Encoding、転送サイズ、元のサイズを確認します。developer.chrome.com↗
2. プロトコルを確認します。 Protocol 列で、実際のリクエストが h3、h2、http/1.1 のどれを使用しているか確認します。
3. 主要なユーザーメトリクスをセグメント化します。 初回訪問と再訪問、モバイルとデスクトップ、地域、ネットワーク種別ごとに、TTFB、LCP、インタラクション指標を比較します。web.dev↗web.dev↗
4. 一度に変更するのは 1 つにします。 gzip の有効化、Brotli サポート、画像置き換え、JavaScript 分割、HTTP/3 有効化を同時に展開すると、どの変更が効果を生んだのかを特定しにくくなります。
5. 副作用も記録します。 サーバー CPU、エラー率、キャッシュヒット率、HTTP/3 接続の失敗率やフォールバック率も監視します。

たとえば、非圧縮の JavaScript バンドルを gzip に切り替えて転送サイズが減っても LCP がほとんど変わらない場合、次のボトルネックは圧縮ではなく、大きな画像、CSS、または JavaScript 実行である可能性が高いといえます。逆に、HTTP/3 導入後にモバイルネットワークユーザーの LCP のロングテールが改善した場合、平均値だけでなく、高ロス・高遅延環境での効果も確認できます。このような結論は、技術名ではなく計測されたボトルネックから導かれます。web.dev↗www.rfc-editor.org↗

まとめ：gzip と HTTP/3 は順位争いではなく補完的な役割として扱う

gzip と HTTP/3 はどちらも Web パフォーマンスに役立ちますが、比較の基準は異なります。gzip はテキストレスポンスの転送バイト数を減らし、HTTP/3 は QUIC ベースの多重化ストリームにより、ネットワークロスが複数リクエストへ与える影響を抑えられます。HTTP/3 の QPACK はヘッダー圧縮であり、gzip や Brotli が担うボディ圧縮を置き換えるものではありません。www.rfc-editor.org↗datatracker.ietf.org↗datatracker.ietf.org↗

最も実践的な優先順位は、まず LCP、TTFB、レンダリングブロック、JavaScript、画像、キャッシュのうち実際のボトルネックを特定することです。テキスト圧縮が欠けているならベースラインとして補い、その後に実ユーザー条件で HTTP/3 を検証します。パフォーマンスは最新技術を 1 つ追加することではなく、ユーザーが待つ最も長い経路を短縮することです。web.dev↗developer.chrome.com↗

参考資料

• HTTP Semantics とコンテンツエンコーディングの仕様www.rfc-editor.org↗
• HTTP/3 標準datatracker.ietf.org↗
• QPACK ヘッダー圧縮標準datatracker.ietf.org↗
• QUIC トランスポート仕様www.rfc-editor.org↗
• Web パフォーマンスと LCP 最適化のガイダンスweb.dev↗
• HTTP 圧縮の概要developer.mozilla.org↗