CloudflareのCache Rulesで個人向けページを誤配信しない設定方法

キャッシュは、地味であるほど安全です。静的なスタイルシート、画像、スクリプトは通常、再利用することで効果が得られますが、ログイン画面、カート、アカウントページ、プレビューは同じようには扱えないことがよくあります。「すべてをキャッシュする」という広範なルールを1つ設定するだけで、ページは速くなる一方、別の人に向けた応答を訪問者に渡してしまうことがあります。速度を最適化する前に、公開コンテンツと個人向けコンテンツの境界線を引いてください。

Cloudflareのデフォルトのキャッシュに関するドキュメントによると、このサービスは一般に特定のファイル拡張子をキャッシュし、HTMLやJSONはデフォルトではキャッシュしません。また、オリジンのキャッシュヘッダーやHTTP応答の特性が、キャッシュの対象になるかどうかにどう影響するかも説明しています。カスタムルールを使うと、これらの前提を変えることができます。だからこそ、チュートリアルから積極的なルールをそのままコピーするのは危険なのです。

対象者と状態でルートを分類する

URLを、公開の静的アセット、匿名の訪問者向けの公開HTML、Cookieやログイン状態によって内容が変わるページ、管理画面、API、挙動を予測できないエンドポイントに分けます。プレビューのリンク、チェックアウトの各段階、コメントの操作、パスワードで保護されたコンテンツは明示的に印を付けてください。ページが訪問者の身元に依存する場合、最初の判断として最も安全なのは、アプリケーションがそれに対応するよう設計されるまで共有キャッシュを回避することです。

オリジンがCache-Control、Set-Cookie、Varyヘッダーをどのように送信しているかを確認します。匿名向けのページでも無害なCookieを設定することがあり、一方で個人向けのページが保護用のヘッダーを設定していないこともあります。URLのパスだけから挙動を推測するより、実際の応答をテストするほうが確実です。

広いルールの前に範囲の狭いルールを作る

Cloudflareのダッシュボードでは、Cache Rulesを使って一致条件の式を選び、一致したリクエストについてキャッシュを回避するか、キャッシュの対象にするかを設定できます。ルール作成ガイドでは、ルールの順序とデプロイの手順を順を追って説明しています。そのホスト名へのすべてのリクエストではなく、公開コンテンツを対象とした限定的なテストから始めてください。

ルールの順序と重なりを考慮してください。ログイン用のパスを対象とした回避ルールが、後に続く広い一致条件によって意図せず上書きされてはいけません。パラメーターの違い、言語ごとのパス、端末別のコンテンツ、Cookieの状態をテストします。キャッシュキーを変更する場合は、コンテンツのバリエーションごとに実際に異なるキーが生成されることを確認してください。

エッジのTTLの上書きには注意する

Edge Cache TTLは、Cloudflareが応答を保持する期間を変えることができ、設定によってはオリジンからの指示を上書きする場合があります。利用可能な設定に関するドキュメントは、各オプションを説明するとともに、その挙動がヘッダーや他の設定と相互に影響することに注意を促しています。安全に無効化できないHTMLに、長い共有TTLを設定してはいけません。

デプロイの前に、パージの手順を決めておきます。編集系の媒体では、更新や訂正をすぐに反映させる必要があります。エッジに保持された誤った記事の見出しは、キャッシュの無効化が該当するすべてのバリエーションに及ばない限り、CMSで修正した後も表示され続ける可能性があります。

匿名と認証済みの比較テストを行う

公開記事にCookieなしでアクセスし、次に通常の認証済みセッションでアクセスします。ネットワークの応答と、キャッシュのステータスを示すヘッダーを確認してください。安全な環境で、別々のテストアカウントを使って繰り返します。個人の名前、トークン、カート、利用者ごとのナビゲーションが、アカウント間で決して混ざらないことを確認してください。リダイレクトとエラーページもテストします。HITはキャッシュルールが正しいことの証明ではありません。何よりもまず正しさが優先です。

各例外の理由、それを承認した人、安全であることが分かっているテスト用URLを記した、簡潔なルール一覧を作っておきます。以前のデプロイから引き継いだ説明のないルールを、誰もその役割を知らないという理由だけでいつまでも残しておくべきではありません。キャッシュの変更は、認証やチェックアウトのリリースと併せて見直してください。

デプロイ後は、オリジンの負荷、キャッシュヒット率、古いコンテンツ、エラー率を監視します。ロールバックに備えて、変更前のルールをすぐに使える状態にしておいてください。正しさに確信が持てない場合は、キャッシュを回避し、別の最適化を試す前にアプリケーション側の取り決めを修正します。

公開ページに見えるルートでも、リクエストヘッダー、国、端末、A/Bテストによって、目に見えない形で内容が変わることがあります。全員に対して1つの表現をキャッシュすると、誤った言語やバリエーションが誤った人に届く可能性があります。カスタムキャッシュキーを設計する前に、どの入力がHTMLの応答を変えるのかを正確に特定してください。Cloudflareはクエリ文字列、ヘッダー、Cookieに関するオプションを説明していますが、すべてのヘッダーをキーに加えると、キャッシュの効率が失われ、予測できない組み合わせが生まれる可能性があります。

重要なルートごとに、Cookieのない初回訪問、匿名での再訪問、認証済みの訪問という3つの異なる状態をテストします。応答のステータス、Cache-Control、Set-Cookie、利用できる場合はCF-Cache-Status、そして表示される内容の短い特徴を記録してください。編集上の訂正と対象を絞ったパージの後にも、同じテストを繰り返します。これは仮定に基づく品質確認の方法であり、特定のサイトの設定について述べたものではありません。

エラーページとリダイレクトには特に注意してください。一時的なメンテナンス用の応答、認証のためのリダイレクト、地域別の転送先を広くキャッシュしすぎると、オリジンが正常でもサイトが停止しているように見えることがあります。ルールはまず小さなパスのパターンに適用し、可能であれば安全なホスト名でテストしてください。症状がはっきりしない場合は、デフォルトの挙動に戻し、キャッシュの対象を広げる前に調査します。

信頼を損なわずに速度を保つ

静的アセットのキャッシュは、個人向けのHTMLに手を加えなくても有用な効果をもたらすことがよくあります。変更はルートの種類ごとに1つずつ行い、例外を書き留め、CMSや認証の更新後にもう一度確認してください。Cloudflareのセキュリティ更新に関する記事では別の保護の問題を扱い、WordPressのステージングガイドでは本番前に変更をテストする方法を扱っています。速いページに価値があるのは、正しいコンテンツを表示している場合だけです。