Core Web Vitalsに合格するための最適なCloudflare設定
ページ速度を最大化するためにCloudflareを設定し、調整すべき設定を理解してください。
CloudflareでCore Web Vitalsを最適化する：有効にすべき設定と避けるべき設定
Cloudflareには、Core Web Vitalsにプラスにもマイナスにも影響する様々な設定があります。パフォーマンスを向上させる設定もあれば、遅延を引き起こしたりページのレンダリングを妨げたりする設定もあります。よく使われるCloudflareの設定と、それらを有効にすべき条件について解説します。
最終レビュー：Arjen Karel（2026年2月）
Cloudflare設定のよくある質問：私はよくクライアントのCloudflare設定をレビューします。CloudflareのようなCDNの設定については本が書けるほどですが、質問のほとんどは「この設定は有効にすべきか？」という単純なものです。この記事では、Core Web Vitalsに関連するよくあるCloudflareの設定について、適切な判断基準とともにその質問にお答えします。
FreeとPro：アップグレードする価値はあるか？
Speed > Optimization
Polish
Polishは、画像の圧縮、メタデータの削除、およびオプションでWebPへの変換を行うことで、Cloudflareドメインでホストされている画像を最適化します。画像の最適化に関する完全なガイドについては、Core Web Vitalsのための画像最適化をご覧ください。
画像サイズを小さくすると、通常は画像のリソース読み込み時間が改善されるため、Largest Contentful Paintが向上します。ただし、LCPは画像のリソース読み込み時間以外の複数の要因に影響されるため、劇的な改善は期待しないでください。
推奨：有効にして、最良の結果を得るために「Lossy WebP」を選択します。PolishはAVIF変換をサポートしていないことに注意してください。AVIFにはCloudflare Image Resizing（別の有料サービス）が必要です。
Mirage（非推奨）
Mirageは2025年9月15日にCloudflareによって非推奨となり、すべてのドメインで自動的に無効化されました。最新のブラウザはloading="lazy"属性によるlazy loadingをネイティブにサポートしているため、MirageのJavaScriptベースのアプローチは不要になりました。
以前のMirageはネットワークの状況に基づいて画像を最適化していました。その実装は「意図的に遅い」ものでした。つまり、ネットワーク速度が測定されるまで画像をブロックしていたのです。このブロックはLayout Shiftsを引き起こす可能性があり、皮肉なことにLargest Contentful Paintを遅くする原因にもなっていました。
推奨：この設定はもう存在しません。古いガイドで見かけても無視してください。
Speed Brain
Speed BrainはSpeculation Rules APIを使用し、将来のナビゲーションをprefetchすることでTime to First Byteを高速化します。Speculation Rulesは、Largest Contentful Paintを含むすべてのCore Web Vitalsの改善に極めて効果的です。Speed Brainは（無料を含む）すべてのプランで利用可能で、現在はconservativeのeagerness levelを使用しています。これはユーザーがリンクをクリックしようとした時にのみprefetchを行います。
Speed Brainに頼ることはおすすめしません。なぜなら、Cloudflareの画一的なアプローチよりも、Speculation Rulesを手動で設定する方が簡単で、はるかに効果的だからです。手動設定であれば、独自のeagerness levelを選択し、特定のURLをターゲットにして、単なるprefetchではなくprerenderingを使用できます。
推奨：無効にして、Speculation Rulesを手動で設定します。自分で設定しないのであれば、Speculation Rulesが全くないよりは、Speed Brainを有効のままにしておく方が良いでしょう。
Cloudflare Fonts
Cloudflare Fontsはフォントのセルフホスティングを自動化します。重要なリソースをセルフホストすることで、新規の外部接続を排除できるため、これは素晴らしいアイデアです。新規の外部接続は、Cloudflareでプロキシされたサイトのすでに開いている接続を再利用するよりも基本的に遅くなります。
15分かけて手動でフォントファイルのセルフホスティングを設定する方が効果的です。残念ながら、多くのCMSではそれができません。その場合、Cloudflare Fontsを有効にするのは完全に理にかなった選択肢です。Cloudflare Fontsはまだベータ版（2023年から）であり、APOが有効な場合は機能しないことに注意してください。
推奨：デフォルトでは無効にします。手動でのセルフホスティングが不可能な場合にのみ有効にします。
Early Hints
Early Hintsは、実際のHTMLコンテンツがブラウザに送信される前にヒントを提示することで、重要なリソース（スタイル、フォント、画像など）の配信を高速化します。Cloudflareを通じてリソースヒントを送信するには、Cloudflareがレスポンスヘッダーを読み取り、そこからリソースヒントを抽出します。
HTTPレスポンスヘッダーでリソースヒントを送信することに抵抗がなければ、この機能を有効にすることを強くお勧めします。ただし、ヘッダー内のリソースヒントは、ページの<head>内のリソースヒントよりも開発チームから見えにくい可能性があることに注意してください。設定を誤ると、速度が向上するどころか遅くなる可能性があります。そのため、注意して使用してください。何年も前から利用可能であるにもかかわらず、2025 Web AlmanacによるとEarly Hintsの採用率は依然として3%未満です。
推奨：リソースヒントヘッダーを正しく送信している場合にのみ有効にします。
Auto Minify
CloudflareはHTML、CSS、JavaScriptをオンザフライでミニファイ（圧縮）できます。HTMLのミニファイは空白とコメントを削除し、転送サイズをわずかに縮小します。CSSとJavaScriptのミニファイも、これらのファイルタイプに対して同じことを行います。
推奨：HTMLのミニファイを有効にします。CSSとJavaScriptについては、（デプロイプロセス中の）ビルド時のミニファイの方が、Cloudflareのオンザフライのアプローチよりも良い結果をもたらします。ビルドプロセスがない場合は、3つすべてを有効にしても問題ありません。
Rocket Loader
Rocket Loaderは、スクリプトを一時的に保留し、少し後にページに注入することで、ウェブページ上のすべてのJavaScriptを「遅延（defer）」させます。これは、すべてのブラウザで正しく動作することを保証するために多くのチェックとハックを必要とする、厄介な（見方によっては巧妙な）トリックです。また、重要なリソースの読み込みを高速化するためのメカニズムであるpreload scannerからスクリプトを隠してしまいます。
当然のことながら、上記のような理由から、私はRocket Loaderを盲目的に有効にすることは推奨しません。スクリプトはその重要性に基づいてスケジュールされるべきです。重要なスクリプトは早く読み込んで実行する必要があり、必須ではないスクリプトはブラウザがアイドル状態になるまで待つことができます。
CloudflareのRocket Loaderはそのようなことはしません。すべてのスクリプトを保留し、重要性を考慮することなく特定の時点でそれらを注入します。Rocket Loaderはスクリプトよりも、LCP要素、フォント、スタイルなどの他のリソースを優先するだけです。さらに、Rocket Loaderはunloadイベントハンドラーを使用します。これはブラウザのBack-Forward Cache（bfcache）の動作を妨げる非推奨のAPIです。つまり、戻る・進むナビゲーションは、瞬時の復元ではなくページ全体の再読み込みを引き起こします。
使用しているCMSがスクリプトの遅延や、よりきめ細かいスクリプトのタイミング制御を許可していない場合、Rocket Loaderが最良の選択肢になる可能性があります。しかし、ほとんどのサイトでは、スクリプトを手動でスケジュールする方がはるかに効果的です。
推奨：無効にして、スクリプトを手動でスケジュールします。スクリプトの実行を遅延または制御する他の方法がない場合にのみ有効にします。
Automatic Platform Optimization for WordPress
CloudflareのAPOはページ全体をエッジサーバーにキャッシュします。これはfull-page edge caching（ページ全体のエッジキャッシュ）として知られる手法です。正しく実装されれば、特定のタイプの訪問者に対するTime to First Byte（およびその結果としてのLCPとFCP）が改善されます。
しかし、注意点があります。フルページエッジキャッシュはしばしば自動的にバイパスされる必要があります。例えば、ユーザーがログインしたりカートにアイテムを追加したりすると、ページコンテンツがパーソナライズされるため、APOは自動的に無効になります。その時点で、一般的なキャッシュページを提供することはもはや不可能です。APOはあらゆるタイプのウェブサイトで機能する必要があるため、あなたのサイトにとって必要以上にキャッシュがバイパスされます。これが、CloudflareのAPOよりも手動でのキャッシュ設定がほぼ常に効果的である理由です。
推奨：APOを有効にします。さらに良いのは、キャッシュがいつバイパスされるかをより適切に制御するために、独自のフルページエッジキャッシュルールを設定することです。
HTTP/2, HTTP/2 to Origin and Enhanced HTTP/2 Prioritization
HTTP/2、HTTP/2 to Origin、およびEnhanced HTTP/2 Prioritizationは迷わず有効にすべきです。HTTP/2は、古いHTTP/1.1プロトコルから大きく改善されています。HTTP/2は多くのことを行いますが、最も重要なのは、複数のファイルを同じ接続上で並行して送信できるようにすることで、古い階段効果（staircase effect）を排除することです。HTTP/2は登場から10年が経過しており、ブラウザやサーバーで広くサポートされています。
推奨：3つすべてを有効にします。
HTTP/3 (with QUIC)
HTTP/3 with QUICは、接続のセットアップとレイテンシの改善により、HTTP/2よりもさらに高速です。HTTP/3では、1つのストリームが遅延した場合でも、複数のストリームを独立して送信できます。QUICはトランスポートと暗号化のハンドシェイクを組み合わせることで、接続時間を短縮します。これにより、TTFBが最大10%高速化します。2025 Web Almanacによると、現在38%のウェブサイトがHTTP/3をサポートしています。
推奨：有効にします。
Brotli Compression
BrotliはGzipよりも小さなファイルを生成する圧縮アルゴリズムです。CloudflareはすべてのプランでデフォルトでBrotliを有効にしています。これが有効なままであることを確認してください。2025 Web Almanacによると、現在CDNで配信されるリクエストの46%がBrotli圧縮を使用しています。
推奨：有効のままにします（デフォルトでオンになっています）。
0-RTT Connection Resumption
0-RTT Connection Resumptionは、ユーザーがサイトを再訪問した際の初期ハンドシェイクをスキップすることで、安全な接続を高速化します。以前に保存された暗号化キーを使用し、データを直ちに送信できるようにすることで、レイテンシを減らしページの読み込み時間を改善します。
推奨：有効にします。
Automatic Signed Exchanges (deprecated)
以前、Signed Exchanges（SXGs）はユーザーのプライバシーを保護しつつ、Google検索がコンテンツをprefetchすることを可能にしていました。SXGsは、Google検索結果からの訪問者に対してLCPを約450ミリ秒改善することができました。
しかし、Cloudflareは2025年10月にSXGsを非推奨としました。この機能は削除され、利用できなくなりました。有効にしていた場合は、自動的に無効化されています。prefetchの最も近い代替機能はSpeed Brain（Speculation Rules）ですが、これは同一サイト内のナビゲーションでのみ機能し、SXGsのようにGoogle検索からのクロスオリジンprefetchには対応していません。
推奨：この設定はもう存在しません。
Scrape Shield
Scrape Shieldはウェブサイト上のコンテンツを保護します。これは良いアイデアのように思えるかもしれませんが、私はScrape Shieldのいかなるオプションも有効にすることに強く反対します。Scrape ShieldはページにJavaScriptを注入し、事前に難読化されたコンテンツをデコードすることで機能します。コンテンツを隠すことと速度のトレードオフは、私には全く意味がわかりません。本物のスパマーを欺くことはできず、本物のユーザーにはページを遅くする余分なスクリプトが送られるだけです。
推奨：Email Address Obfuscationを無効にし、Hotlink Protectionも無効にします。
Bot Fight Mode and Super Bot Fight Mode
これはCore Web Vitalsにとって最も有害なCloudflare設定です。有効にすると、Bot Fight Modeはすべてのページにinvisible.jsというスクリプトを注入します。このスクリプトはブラウザチャレンジを実行し、すべてのページの読み込みに2,000ミリ秒以上のCPU実行時間を追加します。つまり、ページがインタラクティブになる前にmain threadが丸2秒間ブロックされるということです。
実際、Bot Fight Modeを有効にすると、PageSpeedスコアが20ポイント以上低下する可能性があります。Super Bot Fight Modeも同じ問題を抱えています。皮肉なことに、これらのモードはボットをブロックするように設計されていますが、サイトを訪れるすべての本物のユーザーに罰を与えているのです。
推奨：Bot Fight ModeとSuper Bot Fight Modeの両方を無効にします。ボット対策が必要な場合は、代わりにCloudflareのWAFルールまたはレート制限を使用してください。これらはクライアントサイドのJavaScriptを注入しません。
Caching > Configuration
Purge Cache
キャッシュをパージ（消去）すると、スタイルシート、JavaScript、画像、さらにはフルページキャッシュを含め、Cloudflareによってキャッシュされたすべてのファイルが無効になります。キャッシュの消去は厳密には設定ではありませんが、キャッシュをクリアすることには警告が必要です。キャッシュをクリアすると、キャッシュが再構築されるまでサイトが遅くなります。
推奨：可能であれば、キャッシュ全体のパージは避けてください。影響を受けるファイルのみをパージしてください。
Caching Level
キャッシュレベルは、Cloudflareがクエリ文字列をどのように処理するかを決定します。この設定はよく確認する必要があります。
最も「高速」なオプションは「Ignore query string（クエリ文字列を無視）」です。これはクエリ文字列に関係なく同じリソースを提供します。これは、サイトでクエリ文字列が使用されていないと100%確信できる場合にのみ有効なオプションです。その場合、他者が追加したクエリ文字列は無視されます。
「Standard」は、クエリ文字列が異なるごとに異なるキャッシュファイルを提供します。これはCloudflareのデフォルト設定ですが、フルページエッジキャッシュとutmパラメータのようなトラッキングパラメータを組み合わせた場合、キャッシュのミスマッチを引き起こし、キャッシュヒット率を低下させる可能性があります。これを解決するために、Cloudflare Workersでトラッキングパラメータを削除することを検討してください。
推奨：可能な限り「Ignore query string」、または「Standard」を使用します。「No query string」オプションは避けてください。
Browser Cache TTL
Browser Cache TTLは、ブラウザが静的リソースをキャッシュできる期間を指示します。キャッシュされたリソースはブラウザから直接提供されるため、リモートのネットワークリソースよりもはるかに高速に利用できます。つまり、Browser Cache TTLが短いと、ブラウザキャッシュが頻繁に無効になり、キャッシュヒット率が低下します。静的ファイルが頻繁に変更されない限り、この設定は最大値にしてください。
推奨：可能であれば「1 year（1年）」に設定します。
Development Mode
Development mode（開発モード）が有効な間は、すべてのCloudflareキャッシュがバイパスされます。開発中はDevelopment modeを有効にしたくなるかもしれません。しかし、Development modeは有効にしないでください。他のすべての訪問者に対してもキャッシュが無効になってしまいます。代わりに、開発用のドメインを設定するか、キャッシュルールを設定して自分自身をCloudflareキャッシュから除外してください。
推奨：有効にしないでください！
Caching > Tiered Cache
Tiered Cacheは、キャッシュされていないファイルをまず自社サーバー上で探すようCloudflareに指示することで、オリジンサーバーへのリクエスト数を減らし、キャッシュヒット率を高めます。これにより、バックエンドサーバーの負荷がさらに軽減され、余分なリソースが解放されます。
推奨：Smart Tiered Caching Topologyを有効にします。
CoreDashで監視されているサイト全体で、適切に設定されたCDNを使用しているサイトは、CDNを使用していないサイトと比較して、75パーセンタイル（p75）でTTFBが55%高速になっています。CloudflareのHTTP/3、Brotli、そしてTiered Cacheの組み合わせは、フィールドにおいて測定可能な違いをもたらします。Real User Monitoringを使用して、Cloudflareの設定が実際のユーザーに対して本当に機能しているかを確認してください。
