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 タイムアウトも 3 分に短縮されました（Cache-Control: no-store を使用しないページで使用されている 10 分から）。
エンタープライズ向けオプトアウト
企業では、更新が難しいソフトウェアや共有デバイスが使用されていることがよくあります。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 の復元時にデータを更新することを検討することをおすすめします。
更新は、pageshow イベントを使用してアナリティクスの追加のページビューを記録し、persisted プロパティを確認するのと同様にトリガーできます。
すべてのコンテンツを更新する必要はなく、ユーザーは以前に見たコンテンツに「戻る」ことを好む場合があります。たとえば、記事のリストを更新すると、ユーザーが戻って閲覧しようとしていた記事が表示されなくなる可能性があります。
広告への影響
アナリティクスへの影響と同様に、広告がページの読み込み時にのみ読み込まれる場合、サイトの広告インプレッション数が減少する可能性があります。pageshow イベントを使用して persisted プロパティをチェックし、bfcache の復元時に広告をプログラムで更新して、ページ全体の読み込みと広告の表示が一致するようにすることもできますが、必ずしも適切な方法とは限りません。広告の再読み込みをトリガーする方法については、広告プロバイダのドキュメントをご覧ください。
bfcache の詳細
bfcache の詳細については、bfcache の包括的な技術ガイドをご覧ください。
フィードバック
この変更についてご意見、ご感想がございましたら、Chrome の問題トラッカーで bfcache コンポーネントを使用してお寄せください。
まとめ
今後、より多くのページに bfcache のメリットを適用し、ユーザーのページ エクスペリエンスを改善していく予定です。Google は、この変更を慎重に検討し、できるだけ安全な方法でロールアウトする方法を模索してきました。デベロッパーの皆様がこの変更を理解し、問題が発生しないように必要な変更を加えるのに、この情報が役立てば幸いです。