公開日: 2024 年 10 月 21 日、最終更新日: 2025 年 9 月 9 日
Chrome では、Cache-Control: no-store を使用するページで バックフォワード キャッシュ（bfcache）を安全に使用できるように変更が行われています。この変更がデベロッパーに与える影響についてご確認ください。
背景
Cache-Control: no-store を HTTP ヘッダーとして設定すると、ページを HTTP キャッシュに保存しないというシグナルになります。これは、機密データを含むページ（ユーザーがログインしているページなど）で使用する必要がありますが、no-store ディレクティブは機密データを含まないページでもよく使用されます。
bfcache では、ユーザーがページから移動したときにページを破棄するのではなく、破棄を延期して JS の実行を一時停止します。ユーザーがすぐに戻った場合は、ページを再び表示し、JS の実行を再開します。これにより、ユーザーはほぼ瞬時にページを移動できます。
HTML 仕様では必須ではありませんが、ブラウザは通常、Cache-Control: no-store をシグナルとして認識し、ページを bfcache に配置しないようにします。これは、モバイルの履歴ナビゲーションの約 17%、パソコンの履歴ナビゲーションの約 7% で bfcache が使用されない最大の理由です。つまり、これらのページは高速復元を利用できず、ネットワーク呼び出し、JavaScript の実行、レンダリングなど、ページを完全に再読み込みする必要があります。
多くの場合、サイトの変更時にキャッシュ保存の問題を回避するために Cache-Control: no-store が設定されますが、bfcache が使用されている場合は、ページ全体がずっと開いていたかのように復元されるため、この理由はあまり当てはまりません。
Chrome での動作の変更
Chrome はこの動作を変更する意向を発表していますが、この変更には慎重に取り組んでいます。Chrome 116 以降、ページ読み込みの割合を徐々に増やしていくテストを実施しており、2025 年 3 月と 4 月には 100% に達する見込みです。
センシティブ データ
Google の分析では、前後のナビゲーションの大部分には機密データが含まれていないため、bfcache の対象となるはずですが、ページを bfcache に配置すべきでない場合もあります。たとえば、ログアウト時に、前後に移動してログイン済みのページを取得できないようにする必要があります。
これを回避するため、Chrome は Cookie または他の認証方法が変更されたときに、bfcache からページを削除します。
また、Cache-Control: no-store を使用するページで次の API を使用すると、そのページは引き続きバックフォワード キャッシュの対象外になります。
これは bfcache の使用を妨げる API の包括的なリストではなく、ページを離れるときに使用されていなくても Cache-Control: no-store ページで bfcache をブロックする API のリストです。
また、リスクをさらに軽減するため、Cache-Control: no-store ページでのバックフォワード キャッシュのタイムアウトも 3 分（Cache-Control: no-store を使用しないページで使用される 10 分から）に短縮されます。
Enterprise のオプトアウト
企業では、更新が難しいソフトウェアや共有デバイスが使用されていることがよくあります。Cache-Control: no-store ページで bfcache の使用を継続的に防ぐには、AllowBackForwardCacheForCacheControlNoStorePageEnabled ポリシーを無効にできます。
変更をテストする
デベロッパーは、次のフラグを使用してこの変更をテストできます。
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
上記の例外のいずれか（Cookie の変更など）が適用される場合、ページは bfcache を使用できなくなり、Chrome DevTools の bfcache テスターに「Pages whose main resource has Cache-Control: no-store cannot enter back/forward cache.」という理由が表示されます。
この bfcache テストページを使用すると、このフラグの有無によるテストを行えます。
デベロッパーが知っておくべきこと
デベロッパーは、ユーザーが bfcache の使用率向上によるメリットを享受するために変更を加える必要はありませんが、この結果として考慮すべき点がいくつかあります。これは、2021 年 12 月に bfcache が最初にリリースされたときに他のサイトでも発生した可能性のある問題と似ています。
デベロッパーは引き続き Cache-Control: no-store の使用量を減らすことを目指すべきですか？
bfcache は、前述の限られた状況下で Cache-Control: no-store に対して有効になり、Chrome でのみ利用できます。他のブラウザでは、Cache-Control: no-store が使用されている場合でも bfcache の使用がブロックされることがあります。
ベスト プラクティスは、これらのヒューリスティックに依存するのではなく、Cache-Control: no-store の使用を最小限に抑えることです。
パフォーマンスへの影響
この変更を行うのは、ウェブ上のユーザーのページ エクスペリエンスを改善するためです。bfcache を最初にリリースしたとき、ウェブに関する主な指標に顕著な改善が見られました。そこで、同じ改善をより多くのサイトにもたらしたいと考えています。
このロールアウトにより、サイト所有者はウェブに関する主な指標の改善を確認できます。また、CrUX Vis を含む CrUX で bfcache の使用状況を測定できます。
影響分析
bfcache から復元されたページは、ページを再読み込みするのではなく、古いページ（JavaScript ヒープを含む）を「復元」します。多くの一般的な分析プロバイダでは、bfcache からの復元は新しいページビューとして測定されません。これは、ページビューが最初に読み込まれたときにのみトリガーされるためです。
そのため、bfcache を初めて使用するサイトでは、アナリティクスのページ読み込み数が減少する可能性があります。pageshow イベントのリスナーを設定し、persisted プロパティを確認することで、これらのイベントをページビューとしてカウントすることをおすすめします。
// Send a pageview when the page is first loaded.
gtag('event', 'page_view');
// Send another pageview if the page is restored from bfcache.
window.addEventListener('pageshow', (event) => {
if (event.persisted) {
// Page was restored from bfcache, sent another page view.
gtag('event', 'page_view');
}
});
ページの復元時の更新を処理する
以前は bfcache の使用状況を確認できなかったサイトで、ページが新しいデータで完全に再読み込みされるようになったため、デベロッパーは bfcache の復元時にデータを更新することを検討してください。
更新は、pageshow イベントを使用して分析用の追加のページビューを記録し、persisted プロパティをチェックするのと同様の方法でトリガーできます。
すべてのコンテンツを更新する必要があるわけではなく、ユーザーは以前に見たコンテンツに「戻る」ことを好む場合があることに注意してください。たとえば、記事のリストを更新すると、ユーザーが戻って閲覧しようとしていた記事が表示されなくなることがあります。
広告への影響
分析への影響と同様に、広告がページの読み込み時にのみ読み込まれる場合、広告のインプレッション数が減少する可能性があります。bfcache から復元されたときに広告をプログラムで更新して、ページ全体の読み込みとのパリティを確保できます。この場合も pageshow イベントを使用して persisted プロパティを確認しますが、必ずしも適切な方法とは限りません。広告の再読み込みをトリガーする方法については、広告プロバイダのドキュメントを参照してください。
bfcache の詳細
bfcache の詳細については、bfcache の包括的な技術ガイドをご覧ください。
フィードバック
この変更に関するフィードバックは、bfcache コンポーネントを使用して Chrome のバグトラッカーからお寄せください。
まとめ
bfcache のメリットをより多くのページに提供し、ユーザーのページ エクスペリエンスを向上させることができることを嬉しく思います。Google はこの変更を慎重に検討しており、可能な限り安全な方法で展開するよう努めています。この情報が、デベロッパーの皆様がこの変更を理解し、問題が発生しないように必要な変更を行ううえで役立つことを願っています。