PageSpeed改善で「HTTP/3をON」「Brotliを有効化」と言われても、何が変わるのか分かりにくい人は多いと思います。HTTP/3は通信プロトコル、Brotliはテキスト圧縮です。役割が違うため、同じ高速化スイッチとしてまとめない方が理解しやすくなります。
HTTP/3とBrotli・Zstdの役割
| 機能 | 何を改善 | 効きやすい場面 |
|---|---|---|
| HTTP/3 | ブラウザ〜エッジ間の通信 | モバイル・パケットロスがある回線 |
| Brotli | HTML/CSS/JSなどの転送サイズ | テキスト資産が多いページ |
| 画像圧縮 | 画像ファイル容量 | LCP画像・ギャラリー |
| ページキャッシュ | サーバー生成時間 | 未ログイン公開ページ |
CloudflareのHTTP/3はどこまで？
Cloudflare公式ではHTTP/3はFreeを含む全プランで利用できます。ただし2026年8月時点のドキュメントでは、HTTP/3は訪問者とCloudflare edge間で使われ、CloudflareからoriginへのHTTP/3接続は未対応です。「HTTP/3をONにした＝オリジンサーバーまで全部QUIC」という意味ではありません。
Brotli・Zstd・Gzipはどう使い分ける？
Cloudflareの圧縮方式はプランやCompression Rulesによって異なるため、「Cloudflareなら常にBrotli」とは限りません。まずプラン既定値を把握し、最終的にはレスポンスのcontent-encodingで実際の配信方式を確認します。
2026年の既定圧縮をプラン別に確認
| Cloudflare plan | 既定の圧縮（2026年公式資料） | 補足 |
|---|---|---|
| Free | Zstandard (Zstd) | Compression RulesでBrotli/Gzip等へ変更可能 |
| Pro | Brotli | クライアント対応に応じて配信 |
| Business | Brotli | 同上 |
| Enterprise | Gzip | カスタムRuleで変更可能 |
Compression Rulesで優先方式を変更でき、クライアント対応状況によって別方式へフォールバックします。表は「初期状態の目安」、実レスポンスが「最終確認」です。
Cloudflare利用サイトの確認フロー
| 手順 | 確認 | NGなら |
|---|---|---|
| 1 | DNSがproxied | 135のCloudflare設定 |
| 2 | SSLが正常 | Full (strict)確認 |
| 3 | HTTP/3 ON | Speed設定 |
| 4 | Protocol列でh3 | ブラウザ/回線条件を確認 |
| 5 | content-encoding確認 | Compression Rules |
Protocol列とcontent-encodingを確認した後、転送サイズ、TTFB、LCP/INP/CLS、モバイル回線での体感を変更前後で比較します。これで「通信方式が変わった」だけでなく、ユーザー体験へ意味のある差が出たかを判断できます。
PHPやDBが遅くTTFBが長い場合、HTTP/3だけで根本解決しません。139のCloudflare vs server判断や149のサーバー性能へ進んでください。
HTTP/3をONにしてもh3にならない時
ブラウザがHTTP/3を選ぶには、Cloudflare側でHTTP/3が有効、HTTPSが正常、クライアントとネットワークがQUICを許可している必要があります。企業ネットワークや一部VPNではUDPが制限され、HTTP/2へフォールバックすることがあります。フォールバック自体は異常ではありません。
Alt-Svcと接続再利用
HTTP/3対応サイトでは、ブラウザがAlt-Svc等を通じてHTTP/3利用可能性を学習します。初回アクセスと再訪問でProtocolが異なる場合があるため、1回だけの測定で判断しません。DevToolsを開き、複数回リロードしてh3/h2の変化を確認します。
キャッシュ済みレスポンスとの関係
HTTP/3・Brotli・cacheは別レイヤーですが、実際の転送では組み合わさります。たとえばCloudflare cache HITのHTMLがBrotliで圧縮され、h3で訪問者へ送られることがあります。どの層が改善したかを切り分けるため、cf-cache-status、Protocol、content-encodingを同時に確認します。
モバイルでの実確認手順
- PC DevToolsで基本動作確認
- Wi-Fiでスマホ実機表示
- 4G/5G回線で再表示
- 主要記事・カテゴリ・フォームを操作
- Cloudflare AnalyticsやRUMがあれば実ユーザー傾向を確認
回線条件による差が大きい技術なので、PCの有線回線だけで「効果なし」と結論づけないことが大切です。
HTTP/3の効果が見えにくい理由
自宅の高速Wi-Fiで同一地域のサーバーを見ると、HTTP/2でも十分速く差が小さいことがあります。HTTP/3の利点は、モバイル回線やパケットロスがある環境で出やすいため、ラボ測定だけでなく実ユーザーデータも見ます。
圧縮で確認する対象ファイル
HTML、CSS、JavaScript、JSON、SVGなどテキスト系レスポンスを確認します。DevToolsのNetworkでtransfer sizeとresource sizeを比較すると、圧縮が効いているかイメージしやすくなります。
HTTP/3より先に直すべきケース
- LCP画像が数MBある
- TTFBが1秒以上でoriginが明らかに遅い
- 大量の第三者JavaScriptがmain threadを占有
- キャッシュが常にMISS
- SSLリダイレクトが多段化している
この状態ではプロトコル最適化より、画像・origin・cache・JavaScriptの方が効果が大きい可能性があります。147は最後の数％を整える記事ではなく、「通信層が正しく使えているか確認する記事」として使ってください。
HTTP/3とCore Web Vitalsの関係
HTTP/3はネットワーク待ちを減らす可能性がありますが、LCP要素そのものが重い画像なら効果は限定的です。INPも主にJavaScriptのメインスレッド処理が原因なら、プロトコル変更では解決しません。Core Web Vitalsの各指標を原因別に分解してから、HTTP/3の寄与を評価します。
よくある誤解
HTTP/3ならSEO順位が上がる？
プロトコル名そのものが順位を上げるわけではありません。ユーザー体験や実測速度に寄与する可能性はありますが、コンテンツやCore Web Vitalsを含むサイト全体で評価します。
Brotliで画像も小さくなる？
JPEG/WebP/AVIFのような既に圧縮された画像は、Brotliの主対象ではありません。HTML/CSS/JSなどテキスト資産と分けて考えます。
HTTP/2を無効にすべき？
通常はクライアントとのネゴシエーションで適切なプロトコルが選ばれます。HTTP/3だけに固定する発想ではなく、利用可能な経路を増やすイメージです。
検証で使うブラウザを固定する
Chrome、Safari、Firefoxでプロトコル対応や表示の見え方が違うことがあります。測定のたびに条件を変えず、同じ端末・同じ回線・同じURLで比較します。Cloudflare設定変更前後のスクリーンショットとヘッダーを残すと、後から設定差を追いやすくなります。
Cloudflareを使わないサイトの場合
ホスティング側がHTTP/3やBrotliを提供している場合もあります。Cloudflare導入が必須という意味ではありません。現在のレスポンスを確認し、既にh3やbrが使われているなら新しいサービスを足さない判断も合理的です。
変更後に不具合が出たら
HTTP/3そのものより、同時に変更したCompression RulesやCache Rulesが原因のことがあります。通信・圧縮・キャッシュを一度に変えず、変更履歴を分けます。Cloudflare設定は反映が速いので、1項目ごとにシークレットウィンドウと別回線で確認すると原因を絞れます。
最終判断
HTTP/3と現在の圧縮（Zstd/Brotli/Gzip）がすでに正常なら、設定を増やすより画像・JS・origin側の改善へ時間を使います。Cloudflare導入自体は135、CDNの必要性は137、originとサーバーの判断は139へ分離しています。
公式情報・参考資料
まとめ
HTTP/3とZstd/Brotli/Gzipなどの圧縮は「通信層を整える」改善です。大きな画像、遅いPHP、重いDBを直す代わりではありません。まず有効化状態を実測し、ボトルネックが別にあるなら適切な層へ移ります。
コメント