Core Web Vitals に合格するための最適な CloudFlare 設定

Cloudflare で Core Web Vitals を最適化する：有効にすべき設定と避けるべき設定

Cloudflare は Core Web Vitals にプラスにもマイナスにも影響する幅広い設定を提供しています。パフォーマンスを向上させる設定がある一方で、遅延を引き起こしたりページのレンダリングを妨げたりする設定もあります。最も一般的な Cloudflare のオプションと、どのような条件で有効にすべきかを見ていきましょう！

よくある CloudFlare の設定に関する質問：私はクライアントの CloudFlare の設定をよくレビューしています。CloudFlare のような CDN の設定について本が書けるほどですが、ほとんどの質問は単純な 「この設定を有効にすべきですか？」というものです。この記事では、Core Web Vitals に関連する最も一般的な CloudFlare の設定について、適切な考慮事項とともにお答えします。

Free vs. Pro：アップグレードする価値はあるか？

Speed > Optimization

Polish 

Polish は CloudFlare ドメインでホストされている画像を圧縮し、メタデータを除去し、オプションで WebP 画像に変換することで最適化します。 

画像サイズの縮小は通常、画像リソースの読み込み時間を改善することで Largest Contentful Paint を向上させます。ただし、LCP は画像リソースの読み込み時間以外の複数の要因に影響されるため、劇的な改善は期待しないでください！

推奨：有効にし、最良の結果を得るために「Lossy Webp」を選択してください。

Mirage

Mirage はネットワーク状態に基づいて画像を最適化します。このアイデアは素晴らしいのですが、実装は「設計上遅い」ものです。すべてのネットワーク条件に合わせて画像を最適化するために、ネットワーク接続速度が測定されるまでページ上の画像がブロックされます。 この画像のブロックは Layout Shifts を引き起こし、皮肉なことに Largest Contentful Paint スコアの低下につながる可能性があります。

推奨：いかなる状況でも有効にしないでください！

Speed Brain

Speed Brain は Speculation Rules API を使用して、将来のナビゲーションをプリフェッチすることで Time to First Byte を高速化します。Speculation Rules は Largest Contentful Paint を含むすべての Core Web Vitals の改善に非常に効果的ですが、この CloudFlare の機能を有効にすることはお勧めしません。なぜなら、Speculation Rules の「自己設定」は非常に簡単で、CloudFlare の RUM 統合を使用したとしても、CloudFlare の「万能ソリューション」よりもはるかに効果的だからです！ 

推奨：無効にし、Speculation Rules を手動で設定してください

CloudFlare Fonts

CloudFlare Fonts はフォントのセルフホスティングを自動化します。これは素晴らしいアイデアです。重要なリソースをセルフホスティングすることで、新しい外部接続が不要になります。外部接続はデフォルトで、CloudFlare にプロキシされたサイトへの既存の接続を再利用するよりも遅いためです。

15分かけて手動でフォントファイルのセルフホスティングを設定する方がより効果的です。残念ながら、これができない CMS システムも多数あります。その場合、CloudFlare Fonts を有効にすることは完全に有効な選択肢です。

推奨：デフォルトでは無効にし、手動でのセルフホスティングができない場合のみ有効にしてください。

Early Hints

Early Hints は、実際の HTML コンテンツがブラウザに送信される前にリソース（スタイル、フォント、画像など）をヒントとして送ることで、重要なリソースの配信を高速化します。CloudFlare を通じてリソースヒントを送信するために、CloudFlare はレスポンスヘッダーを読み取り、そこからリソースヒントを抽出します。 

HTML レスポンスヘッダーでリソースヒントを送信することに慣れている場合、この機能を有効にすることを強くお勧めします。ただし、リソースヒントはページの head 内のリソースヒントよりも開発チームにとって見えにくくなる可能性があることに注意してください。設定を誤ると、高速化ではなく低速化を引き起こす可能性があります。慎重に使用してください。

推奨：リソースヒントヘッダーを正しく送信している場合のみ有効にしてください。

Rocket Loader™

Rocket Loader はウェブページ上のすべての JavaScript を一時的に保留し、数秒後にページに再度挿入することで「遅延」させます。 これは、すべてのブラウザで正しく動作するために多くのチェックとハックが必要な巧妙な（または厄介な、見方によりますが）トリックです。また、このトリックはプリロードスキャナーからスクリプトを隠します。プリロードスキャナーは重要なリソースの読み込みを高速化するために設計されたメカニズムです。

上記の理由から、当然ながら Rocket Loader を盲目的に有効にすることには賛成できません。 スクリプトはその重要度に基づいてスケジュールされるべきです。重要なスクリプトは早期に読み込んで実行する必要があり、重要でないスクリプトはブラウザがアイドル状態になるまで待つことができます。

CloudFlare の Rocket Loader はそうしません。スクリプトを保留し、ある時点でその重要度を考慮せずに挿入します。Rocket Loader は LCP 要素、フォント、スタイルなどの他のリソースをスクリプトよりも優先するだけです。CMS がスクリプトの遅延やより細かいスクリプトタイミングを許可しない場合、Rocket Loader が最良の選択肢になる可能性があります。

推奨：無効にし、スクリプトを手動でスケジュールしてください。スクリプトの遅延や実行制御ができない場合のみ有効にしてください。

WordPress 向け Automatic Platform Optimization

CloudFlare の APO はページ全体をエッジサーバーにキャッシュします。これはフルページエッジキャッシングと呼ばれる技術です。正しく実装されると、特定のタイプの訪問者の Time to First Byte（そしてその結果として LCP と FCP）が改善されます！ 

ただし、注意点があります。フルページエッジキャッシングは自動的にバイパスされる必要がある場合が多いです。例えば、ユーザーがログインしたりカートに商品を追加したりすると、ページコンテンツがパーソナライズされるため APO は自動的に無効になります。その時点で、汎用的なキャッシュページを提供することはもはや選択肢ではありません。APO はすべてのタイプのウェブサイトで動作する必要があるため、キャッシュはサイトにとって必要以上に頻繁にバイパスされます。そのため、手動のキャッシュ設定は CloudFlare の APO よりもほぼ常に効果的です

推奨：APO を有効にするか、さらに良いのは、キャッシュがバイパスされるタイミングをより細かく制御するために独自のフルページエッジキャッシングルールを設定することです。

HTTP/2 & HTTP/2 to Origin & Enhanced HTTP/2 Prioritization

HTTP/2、HTTP/2 to Origin、Enhanced HTTP/2 Prioritization の有効化は当然のことです。 HTTP/2 は古い HTTP/1.1 プロトコルに対する大幅な改善です。HTTP/2 は多くのことを行いますが、最も重要なのは、同じ接続で複数のファイルを並行して送信できるようにすることで、古い階段効果を排除することです。HTTP/2 は10年前から存在し、ブラウザとサーバーに広くサポートされています！

推奨：有効にしてください

HTTP/3（QUIC 対応）

HTTP/3（QUIC 対応）は、接続のセットアップとレイテンシーの改善により HTTP/2 よりもさらに高速です。基本的に HTTP/3 は、1つのストリームが遅延しても複数のストリームを独立して送信できます。QUIC はトランスポートと暗号化のハンドシェイクを統合し、接続時間を短縮します。これにより、TTFB が最大10%高速化されます！

推奨：有効にしてください

0-RTT Connection Resumption

0-RTT Connection Resumption は、ユーザーがサイトを再訪問した際に初期ハンドシェイクをスキップすることで、セキュアな接続を高速化します。以前保存された暗号化キーを使用し、データを即座に送信できるため、レイテンシーが削減されページ読み込み時間が改善されます。 

推奨：有効にしてください

Automatic Signed Exchanges (SXGs)

Signed Exchanges (SXG) により、Google Search はユーザーのプライバシーを保護しながらコンテンツをプリフェッチできます。つまり、Google Search に表示される結果は、プライバシーを保護する方法でいくつかの重要なリソース（HTML、JavaScript、CSS、画像、フォントなど）をプリフェッチする場合があります。Automatic Signed Exchanges は Largest Contentful Paint と Time to First Byte を改善します！

推奨：有効にしてください

Scrape Shield

Scrape Shield はウェブサイトのコンテンツを保護します。これは良いアイデアに思えるかもしれませんが、Scrape Shield のオプションを有効にすることには強く反対です。Scrape Shield は、以前に難読化されたコンテンツをデコードするために JavaScript をページに注入することで動作します。コンテンツを隠すことと速度のトレードオフは私には理解できません。本物のスパマーは騙されず、本物のユーザーはページを遅くする追加のスクリプトを受け取ることになります。

推奨：Email Address Obfuscation を無効にし、Hotlink Protection を無効にしてください

Caching > Configuration

Purge Cache

キャッシュのパージは、スタイルシート、JavaScript、画像、さらにはフルページキャッシュを含む CloudFlare にキャッシュされたすべてのファイルを無効にします。キャッシュのパージは厳密には設定ではありませんが、キャッシュのクリアについて警告しなければなりません。キャッシュをクリアすると、キャッシュが再構築されるまでサイトが遅くなります！

推奨：可能な限りキャッシュ全体のパージを避けてください。影響を受けたファイルのみパージしてください！

Caching Level

キャッシュレベルは CloudFlare がクエリ文字列をどのように処理するかを決定します（確かに「名前にどんな意味があるのか！」ですね）。この設定はよく確認する必要があります。 

最も「高速」なオプションは「クエリ文字列を無視」です。これはクエリ文字列に関係なく同じリソースを配信します。これはサイトでクエリ文字列が使用されていないことが100%確実な場合にのみ良い選択肢です。その場合、他者が追加したクエリ文字列は無視されます。

「Standard」はすべての異なるクエリ文字列に対して異なるキャッシュファイルを配信します。これは CloudFlare のデフォルト設定ですが、フルページエッジキャッシングと utm パラメータなどのトラッキングパラメータとの組み合わせでは、キャッシュの不一致やキャッシュヒット率の低下を引き起こす可能性があります！

推奨：可能な限りクエリ文字列を無視するか Standard を選択し、可能な限り「No query string」オプションは避けてください。

Browser Cache TTL

Browser Cache TTL はブラウザが静的リソースをキャッシュできる期間を指定します。キャッシュされたリソースはブラウザから直接配信でき、リモートネットワークリソースよりもはるかに高速に利用できます。つまり、短い Browser Cache TTL はブラウザキャッシュを頻繁に無効にし、キャッシュヒット率を低下させます。静的ファイルが頻繁に変更されない限り、この設定を最大に設定してください。 

推奨：可能であれば1年に設定してください

Development Mode

Development Mode を有効にすると、すべての CloudFlare キャッシングがバイパスされます。開発中に Development Mode を有効にしたくなるかもしれませんが、有効にしないでください。他のすべての訪問者のキャッシングも無効になります。代わりに、開発用ドメインを設定するか、キャッシュルールを設定して自分自身を CloudFlare キャッシングから除外してください。

推奨：有効にしないでください！

Caching > Tiered Cache

Tiered Cache はオリジンサーバーへのリクエスト数を削減し、CloudFlare に対してキャッシュされていないファイルをまず自社サーバーで検索するよう指示することでキャッシュヒット率を向上させます。これによりバックエンドサーバーの負荷がさらに軽減され、追加のリソースが解放されます。

推奨：Smart Cache Topology を有効にしてください