Chrome では、Cache-Control: no-store を使用するページで、安全な場合にバックフォワード キャッシュ（bfcache）を使用できるように変更されます。デベロッパーにとっての意味を確認してください。
背景
Cache-Control: no-store を HTTP ヘッダーとして設定すると、そのページを HTTP キャッシュに保存してはならないというシグナルになります。これは、機密データを含むページ（ユーザーがログインしているページなど）に使用する必要がありますが、no-store ディレクティブは機密データのないページで使用されることがよくあります。
bfcache を使用すると、ユーザーの移動時にページを破棄するのではなく、破棄を延期し、JS の実行を一時停止します。ユーザーがすぐに戻ってきた場合、ページは再び表示され、JS の実行が一時停止されなくなります。これにより、ユーザーはページをほぼ瞬時に移動できるようになります。
HTML 仕様では必須ではありませんが、通常、ブラウザは Cache-Control: no-store をシグナルとして受け取り、ページを bfcache に配置しないようにします。これが bfcache が使用されない最大の理由です。モバイルの履歴ナビゲーションの約 17%、パソコンでの履歴ナビゲーションの 7% を占めています。つまり、これらのページはクイック復元の恩恵を受けず、ネットワーク呼び出し、JavaScript の実行、レンダリングなど、ページを完全に再読み込みする必要があります。
多くの場合、サイトの変更時にキャッシュに関する問題が発生しないように Cache-Control: no-store が設定されますが、bfcache を使用する場合は、ページ全体が開いたままだったかのように復元されるため、この理由はあまり関係ありません。
Chrome によるこの動作の変更
Chrome ではこの動作を変更する意向を発表していますが、この変更には慎重なアプローチをとっています。このテストは Chrome 116 以降に実施されており、最近までページ読み込みの 5% で実施されていました。
10 月 2 日にこの割合をページ読み込みの 10% に引き上げ、11 月には 20%、来年初めには 50% に引き上げ、その後まもなく完全にリリースする予定です。一部のオプトアウトについては、後述します。
センシティブ データ
分析によると、ほとんどの「戻る」または「進む」ナビゲーションには機密データが含まれないため、bfcache の対象となるはずですが、ページを bfcache に保存しないほうがよい場合もあります。たとえば、ログアウトしたときに、前後に移動してログイン済みのページを取得できないようにする必要があります。
これを回避するため、Chrome では、Cookie やその他の認証方法が変更されると、bfcache からページが削除されます。
また、Cache-Control: no-store を使用するページで次の API を使用すると、引き続きそのページは bfcache の対象外になります。
なお、このリストは bfcache の使用を防止する API の包括的なリストではなく、ページを離れる時点で使用されていない場合でも、Cache-Control: no-store ページで bfcache をブロックする API の包括的なリストです。
リスクをさらに軽減するため、Cache-Control: no-store ページの bfcache タイムアウトも（Cache-Control: no-store を使用しないページでの 10 分から）3 分に短縮されます。
企業向けのオプトアウト
多くの企業では、更新が難しいソフトウェアと共有デバイスがあります。AllowBackForwardCacheForCacheControlNoStorePageEnabled ポリシーを無効にすると、Cache-Control: no-store ページで bfcache の使用を継続的に防ぐことができます。
変更のテスト
デベロッパーは、次のフラグを使用してこの変更をテストできます。
--enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
上記の例外（Cookie の変更など）のいずれかが適用されると、ページは bfcache を使用できなくなり、Chrome DevTools の bfcache テスターに「メイン リソースに Cache-Control: no-store があるページはバックフォワード キャッシュに保存できません」という理由が表示されます。
このフラグの有無をテストするには、bfcache テストページを使用します。
デベロッパーが知っておくべきこと
デベロッパーは、ユーザーがこの bfcache の使用量の増加のメリットを享受できるようにするために変更を行う必要はありませんが、この変更に伴い、デベロッパーが検討する必要がある点がいくつかあります。これらは、2021 年 12 月の bfcache の初回リリース時に他のサイトが経験した可能性がある考慮事項と同様のものです。
パフォーマンスへの影響
この変更は、ウェブ上のユーザーのページ エクスペリエンスを向上させるためです。bfcache を初めてリリースした際、ウェブに関する主な指標が大幅に改善されました。今回、その改善をより多くのサイトに提供したいと考えています。
サイトオーナーは、この機能のリリースに伴い Core Web Vitals の改善を確認できる可能性があります。また、CrUX で bfcache の使用状況を測定（CrUX ダッシュボードを含む）することもできます。
影響分析
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 の使用が表示される可能性があるため、デベロッパーは bfcache の復元時にデータの更新を検討することをおすすめします。
更新は、pageshow イベントを使用してアナリティクスの追加のページビューを記録し、persisted プロパティを確認するのと同様にトリガーできます。
すべてのコンテンツを更新する必要があるわけではなく、ユーザーは前に見たコンテンツに戻ることを好む可能性があります。たとえば、記事のリストを更新すると、閲覧していた記事が表示されなくなる場合があります。
広告への影響
アナリティクスへの影響と同様に、広告がページの読み込み時にのみ読み込まれる場合、サイトの広告インプレッション数が減少する可能性があります。bfcache の復元時に広告をプログラムによって更新し、ページ全体の読み込みと同等にすることができます。これも pageshow イベントを使用し、persisted プロパティを確認しますが、必ずしも適切な処理であるとは限りません。広告の再読み込みをトリガーする方法については、広告プロバイダのドキュメントをご覧ください。
bfcache の詳細
bfcache の詳細については、bfcache の包括的な技術ガイドをご覧ください。
フィードバック
この変更についてご意見、ご感想がございましたら、Chrome の問題トラッカーで bfcache コンポーネントを使用してお寄せください。
まとめ
ユーザーのページ エクスペリエンスを向上させるために、より多くのページで bfcache のメリットを享受できることを嬉しく思います。Google は、この変更を慎重に検討し、できるだけ安全な方法でロールアウトする方法を模索してきました。デベロッパーの皆様がこの変更を理解し、問題が発生しないように必要な変更を加えるのに、この情報が役立てば幸いです。