ページキャッシュ、CDN、同意バナー：誤った同意状態を配信しないための方法
高速なページ、誤った同意
ページキャッシュは、速度とホスティングコストのために実施できる最良の施策の一つです。同時に、気づかないうちに同意設定を壊してしまう最も簡単な原因の一つでもあります。キャッシュは指示されたとおりに動作します。レスポンスを一度保存し、同じキーに一致する全員に配信します。その保存されたレスポンスに、ある訪問者の同意の選択や所在地に固有のものが含まれていれば、次の訪問者もそれを受け取ってしまいます。
このガイドでは、パブリッシャーのサイトの前段に通常置かれるキャッシュ層（CDNのエッジキャッシュ、フルページキャッシュのプラグイン、リバースプロキシ、サービスワーカー、そしてブラウザ自体）と、それぞれが誤った同意体験を配信しないようにする方法を扱います。
基本ルール：キャッシュされるHTMLに同意を含めない
最も安全なアーキテクチャは、キャッシュされるHTMLページを同意に中立な状態でレンダリングすることです。ページにはCMPのローダーと、ブロックまたは待機状態のタグが含まれますが、その特定の訪問者に関する判断は含まれません。その後、CMPがブラウザ内で動作し、保存された選択を読み取り、バナーを表示するかを決め、それに応じてタグを解放します。
問題は、サーバーがレンダリング時に同意の判断を行うときに始まります。たとえば次のような場合です。
- 同意Cookieがあるときにだけ広告や分析のタグを出力するテーマやプラグイン
- すでに選択済みの訪問者に対してバナーのマークアップを省略するサーバーサイドのコード
- 訪問者の同意状態をインラインスクリプトの変数に埋め込むテンプレート
そのようなページがキャッシュされると、最初の訪問者の状態が全員の状態になります。トラッキングを拒否した訪問者が、すでにタグが有効なページを受け取ることもあれば、すでにバナーを閉じた人から作られたキャッシュのせいで、新規の訪問者がバナーをまったく見ないこともあります。
「Vary: Cookie」が答えになることが少ない理由
訪問者ごとに異なるコンテンツへの教科書的な対処法は、キャッシュにCookieヘッダーでの分岐を指示することです。しかし実際には、訪問者は固有の値を持つ多数のCookieを持っているため、Cookieヘッダー全体で分岐すると、通常キャッシュヒット率はほぼゼロになります。CDNによっては、単一のCookieの値からキャッシュキーを作成できます。同意Cookieの取り得る状態が少数であれば実用的ですが、複雑さが増し、キャッシュされるコピーの数も増えます。判断をブラウザに移す方が単純で、キャッシュの効率も保てます。
エッジでの地域判定
多くのパブリッシャーは、地域によってバナーを出し分けています。EUと英国にはオプトインのバナー、米国の州にはオプトアウトの通知、その他の地域にはより軽いものです。サーバーが訪問者のIPアドレスからバリアントを選び、そのページがキャッシュされると、欧州の読者がキャッシュされた米国向けのページを受け取ったり、その逆が起きたりします。
これを避ける3つのパターンがあります。
- クライアント側のジオロケーション。 CMPにブラウザ内で地域を判定させ、キャッシュされるHTMLを全員で同一に保ちます。
- キャッシュキーに国を含める。 エッジで判断せざるを得ない場合は、CDNが提供する国コードをキャッシュキーに含めます。国ごとに1つのキャッシュコピーとなり、挙動が予測可能です。
- キャッシュされないエッジロジック。 地域の判断をエッジ関数で実行し、それ以外はキャッシュされるページに、小さなキャッシュされない値を挿入します。
どれを選ぶにしても、文書化してください。地域に関するバグは再現が最も難しいものの一つです。ある場所の訪問者が、たまたま別の場所の誰かによってキャッシュされたページを受け取った場合にだけ現れるからです。
CMPスクリプト自体のキャッシュ
CMPのローダーを長期間キャッシュすることはパフォーマンスには有益ですが、設定を変更するときにコストが生じます。ベンダー、目的、バナーのテキストを更新しても、スクリプトや設定ファイルが1年間キャッシュされていると、一部の訪問者は古いバージョンを見続けます。CMPがファイルをどのようにバージョン管理しているかを確認してください。ファイル名やバージョンパラメータが変わる方式なら、積極的にキャッシュしつつ、変更を即座に展開できます。また、CMPがクエリ文字列に依存している場合、自社のCDNがサードパーティのスクリプトURLからクエリ文字列を取り除いていないことも確認してください。
サービスワーカーとオフラインキャッシュ
プログレッシブウェブアプリの層を持つサイトでは、サービスワーカーでHTMLをキャッシュすることがよくあります。同じルールが適用されます。特定の同意の判断を反映したページは決して保存しないでください。同意関連のエンドポイントや設定センターのページはサービスワーカーのキャッシュから除外し、新しいCMPの設定を常に取得できるようにしてください。
戻る/進むキャッシュ
最近のブラウザは、直前に訪れたページをメモリに保持し、戻るボタンで即座に復元します。訪問者があるページで設定センターを開いて同意を撤回し、その後に戻るボタンを押すと、復元されたページでは、撤回前のタグがまだ動作している可能性があります。pageshowイベントを監視し、そのpersistedプロパティを確認してください。ページがこのキャッシュから復元された場合は、保存された同意状態を再度読み取り、それに合わせてタグを停止または開始します。
テストの手順
- クリーンなセッションでページを読み込み、拒否してから2つ目のページを読み込み、トラッキングタグが発火しないことを確認する。
- 別のクリーンなブラウザで繰り返し、バナーが表示されることを確認する。これにより、バナーがキャッシュで消えていないことが証明されます。
- レスポンスヘッダーでページがキャッシュから配信されているかを確認し、同意Cookieの有無でHTMLを比較する。同一であるはずです。
- キャッシュをパージした後に少なくとも2つの地域からテストし、キャッシュが温まった後にもう一度テストする。
- 同意を撤回して戻るボタンを使い、タグが停止することを確認する。
重要なポイント
- キャッシュされるHTMLは同意に中立にし、判断はブラウザ内のCMPに任せる。
- Cookieヘッダー全体での分岐は避ける。ヒット率を壊してしまう。
- バナーが地域によって異なる場合は、クライアント側で判断するか、国をキャッシュキーに加える。
- CMPのファイルにバージョンを付け、長いキャッシュ期間が設定変更を遅らせないようにする。
- サービスワーカーと戻る/進むキャッシュに対処し、パージ直後だけでなく、キャッシュが温まった状態でもテストする。