「戻る」操作でページ全体が再読み込みされる場合は、バック・フォワードキャッシュ（bfcache）を確認しましょう。有用な検証には、具体的な遷移手順と既知の初期状態が必要です。一度成功しても、その後のすべての「戻る」操作で復元されるとは限りません。
遷移手順を決める
一般公開されている商品ページや記事ページを選びます。そこから別のページに移動し、ブラウザーの「戻る」ボタンで戻ってください。使用したブラウザー、バージョン、ページを記録します。戻った後も、フィルター、スクロール位置、表示内容が適切かを確認しましょう。
Milten の bfcache テストは、ページの復元を調べるのに役立ちます。結果がどの遷移手順を対象としているかを確認してください。手動で別の経路をたどると、結果が異なる場合があります。
ブラウザで結果を表示する
Chrome DevTools の Application パネルには、バック・フォワードキャッシュのテストがあります。テスト結果と、復元を妨げる原因が報告されていれば、その内容を確認できます。結果は、検証したブラウザーとバージョンを前提に解釈してください。
bfcache と HTTP キャッシュは異なる仕組みです。Google の bfcache ガイドでは、その違いを説明しています。web.dev で解説を確認できます。ネットワークリクエストが速くなっただけでは、bfcache から復元された証拠にはなりません。
報告された原因を調べる
顧客データを使わない説明用の例です。診断ツールが、組み込まれたスクリプトのライフサイクルイベントハンドラーを復元の妨げとして報告したとします。該当するスクリプトを特定し、ハンドラーの役割を確認します。適切な変更を非公開のテスト環境で検証してから、同じ遷移手順を再実行してください。
テストに通ることだけを目的に、キャッシュヘッダーを一律に変更しないでください。ページの目的と、情報の鮮度や機密性に関する要件を考慮します。bfcache の利用条件もブラウザーによって異なります。
戻った後のページの状態を確認する
変更後は技術的な結果だけでなく、ページの内容も確認します。価格、カートの中身、セッション状態を扱うページでは、それらが正しいかを確認してください。復元したページに、誤解を招く古い情報が表示されてはいけません。
利用者が実際に使うブラウザーで同じ手順を繰り返します。成功、失敗、未実施の試行を分けて記録してください。戻った後の操作が遅い場合は、INP ガイドを参照してください。
必ず復元させることはできますか？
キャッシュを使うかどうかはブラウザーが判断します。成功したテストが示すのは、その試行で観測した結果です。
キャッシュの制限をすべて解除すべきですか？
まず、報告された原因と制限の目的を確認してください。変更の評価には、保護要件と表示内容の正確さも含めます。
ページの bfcache を確認する。初回読み込みを調べるには、速度テストを利用してください。
