バックフォワード キャッシュ

Philip Walton
Barry Pollard

バックフォワード キャッシュ（bfcache）は、すぐに前後に移動できるブラウザの最適化です。これにより、特に低速のネットワークやデバイスを使用するユーザーのブラウジング エクスペリエンスが大幅に向上します。

ウェブ デベロッパーにとって、ユーザーがメリットを享受できるように、ページを bfcache 用に最適化する方法を理解しておくことは重要です。

ブラウザの互換性

bfcache は、パソコンとモバイルの Firefox と Safari の両方で長年にわたってサポートされています。

Chrome バージョン 86 以降では、ごく一部のユーザーを対象に、Android のクロスサイト ナビゲーション用に bfcache が有効になっています。今後のリリースでは、追加のサポートが段階的にリリースされます。バージョン 96 以降では、パソコンとモバイルを使用するすべての Chrome ユーザーに対して bfcache が有効になっています。

bfcache の基本

bfcache は、ユーザーがページから移動するときにページの完全なスナップショット（JavaScript ヒープを含む）を保存するメモリ内キャッシュです。ページ全体がメモリ内に格納された状態になっているため、ユーザーがページに戻ることにした場合、ブラウザはすばやくページを復元できます。

ウェブサイトにアクセスし、リンクをクリックして別のページに移動したものの、意図したものではないことに気づいて [戻る] ボタンをクリックしたことは何回ありますか？その際に、bfcache によって前のページの読み込み速度が大きく変わります。

bfcache が無効な場合 前のページが読み込まれる新しいリクエストが開始されます。そのページが繰り返しアクセスするように 最適化されている度合いによっては、ブラウザでダウンロードしたリソースの一部（またはすべて）を再ダウンロード、再解析、再実行する必要がある場合があります。
bfcache が有効な場合 前のページの読み込みは、実質的に即時に行われます。ネットワークにアクセスしなくても、ページ全体をメモリから復元できるためです。

bfcache によって移動を高速化できる仕組みについては、こちらの動画をご覧ください。

bfcache を使用すると、「戻る」や「進む」ナビゲーション中のページの読み込み速度が大幅に上がります。

動画では、bfcache を含む例は、使用しない例よりもかなり高速です。

bfcache を使用すると、ナビゲーションが高速化されるだけでなく、リソースを再度ダウンロードする必要がないため、データ使用量も削減できます。

Chrome の使用状況データによると、パソコンでのナビゲーションの 10 分の 1、モバイルでの 5 分の 1 は、「戻る」または「進む」です。bfcache を有効にすると、毎日何十億ものウェブページのデータ転送や読み込みにかかる時間を節約できます。

「キャッシュ」の仕組み

bfcache で使用される「キャッシュ」は、HTTP キャッシュとは異なります。HTTP キャッシュは、メモリ内のページ全体（JavaScript ヒープを含む）のスナップショットです。これに対して、HTTP キャッシュには以前に行われたリクエストに対するレスポンスのみが含まれます。HTTP キャッシュからページを読み込む必要があるすべてのリクエストが HTTP キャッシュから実行されることはまれであるため、bfcache による復元を使用した再アクセスは、適切に最適化された bfcache 以外のナビゲーションよりも常に高速になります。

しかし、メモリ内にページのスナップショットを作成する場合、作成中のコードの最適な保存方法に関して多少の複雑さが伴います。たとえば、ページが bfcache にある間にタイムアウトに達した setTimeout() 呼び出しをどのように処理しますか。

ブラウザは bfcache 内のページに対する保留中のタイマーや未解決の Promise（JavaScript タスクキューのほぼすべての保留中のタスクを含む）を一時停止し、ページが bfcache から復元されるとタスクの処理を再開するというものです。

タイムアウトや Promise など、リスクが非常に低い場合もありますが、混乱や予期しない動作につながる場合もあります。たとえば、IndexedDB トランザクションの一部として必要なタスクをブラウザが一時停止すると、同じ IndexedDB データベースに複数のタブから同時にアクセスできるため、同じオリジンで開いている他のタブに影響する可能性があります。そのため、ブラウザは通常、IndexedDB トランザクションの途中や、他のページに影響する可能性のある API を使用している間は、ページをキャッシュに保存しようとしません。

API のさまざまな用途がページの bfcache の利用資格に及ぼす影響について詳しくは、bfcache 用にページを最適化するをご覧ください。

bfcache と iframe

ページに iframe が埋め込まれている場合、iframe 自体は bfcache の対象になりません。たとえば、iframe 内の別のページに移動してから戻ると、ブラウザはメインフレーム内ではなく iframe 内で「戻る」動作を行いますが、iframe 内の「戻る」ナビゲーションでは bfcache は使用されません。

また、埋め込み iframe が bfcache をブロックする API を使用している場合は、メインフレームで bfcache の使用がブロックされることがあります。この問題を回避するには、メインフレームに設定した権限ポリシーを使用するか、sandbox 属性を使用します。

bfcache とシングルページ アプリ（SPA）

bfcache はブラウザが管理するナビゲーションで動作するため、シングルページ アプリ（SPA）内の「ソフト ナビゲーション」では機能しません。ただし、SPA に戻す場合は、最初からアプリを完全に再初期化するのではなく、bfcache が役立ちます。

bfcache を監視するための API

bfcache はブラウザによって自動的に行われる最適化ですが、デベロッパーが bfcache に基づいてページを最適化し、それに応じて指標やパフォーマンスの測定を調整できるように、bfcache が行われるタイミングを把握しておくことは重要です。

bfcache の監視に使用される主なイベントは、ページ遷移イベントの pageshow と pagehide です。これらはほとんどのブラウザでサポートされています。

新しいページ ライフサイクル イベント（freeze と resume）は、ページが bfcache に出入りしたとき、また他の状況（CPU 使用率を最小限に抑えるためにバックグラウンドのタブがフリーズした場合など）でもディスパッチされます。これらのイベントは Chromium ベースのブラウザでのみサポートされています。

ページが bfcache から復元されたことを確認する

pageshow イベントは、load イベントの直後（ページが最初に読み込まれるとき）と、ページが bfcache から復元されるたびに呼び出されます。pageshow イベントには persisted プロパティがあります。これは、ページが bfcache から復元された場合は true、それ以外の場合は false です。persisted プロパティを使用すると、通常のページ読み込みと bfcache 復元を区別できます。次に例を示します。

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    console.log('This page was restored from the bfcache.');
  } else {
    console.log('This page was loaded normally.');
  }
});

Page Lifecycle API をサポートしているブラウザでは、ページが bfcache から復元されたとき（pageshow イベントの直前）と、ユーザーがフリーズしたバックグラウンド タブに再度アクセスしたときに、resume イベントが発生します。凍結されたページの状態（bfcache 内のページを含む）を更新する場合は resume イベントを使用しますが、サイトの bfcache のヒット率を測定する場合は pageshow イベントを使用する必要があります。場合によっては、両方を使用する必要があります。

bfcache 測定のベスト プラクティスについて詳しくは、bfcache が分析とパフォーマンス測定に及ぼす影響をご覧ください。

ページが bfcache に入ったタイミングを監視する

pagehide イベントは、ページがアンロードされたとき、またはブラウザがページを bfcache に追加しようとしたときに呼び出されます。

pagehide イベントには persisted プロパティもあります。それが false であれば、そのページは bfcache に入ろうとしていると確信できます。ただし、persisted が true であっても、ページがキャッシュされるとは限りません。ブラウザがページをキャッシュintendsものの、キャッシュできない要因が他の要因にある可能性があります。

window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    console.log('This page *might* be entering the bfcache.');
  } else {
    console.log('This page will unload normally and be discarded.');
  }
});

同様に、persisted が true の場合、freeze イベントは pagehide イベントの直後に発生しますが、これはブラウザがページをキャッシュしようとしていたことを意味するだけです。intends後述するさまざまな理由で、さらにデータを破棄しなければならない場合があります。

bfcache 用にページを最適化する

すべてのページが bfcache に保存されるわけではなく、ページが bfcache に保存されるわけでも、無期限に保持されるわけではありません。キャッシュ ヒット率を最大化するには、デベロッパーがページを bfcache の対象（および対象外）にする要因を理解することが重要です。

以下のセクションでは、ブラウザでページを可能な限りキャッシュに保存できるようにするためのベスト プラクティスの概要を説明します。

unload イベントを使用しない

すべてのブラウザで bfcache を最適化するうえで最も重要な方法は、unload イベントを使用しないことです。そうね！

unload イベントは、bfcache より前から存在しており、インターネット上の多くのページは、unload イベントの発生後にそのページが存在しなくなるという（合理的な）前提に基づいて動作するため、ブラウザにとって問題となります。しかし、多くのページはユーザーがページから移動するたびに unload イベントが発生することを想定して作成されているため、これは困難です。これはもはや真実ではありません（また、長期にわたって当てはまっていません）。

そのためブラウザはジレンマに直面しており、ユーザー エクスペリエンスを向上させるものを選択しなければなりません。ただし、ページを開けなくなる恐れもあります。

パソコンでは、Chrome と Firefox によって、unload リスナーを追加するとページが bfcache の対象外になります。これはリスクは低いですが、多くのページが対象から除外されます。Safari は unload イベント リスナーを使用して一部のページをキャッシュしようとしますが、破損の可能性を減らすために、ユーザーがページから移動している間は unload イベントが実行されないため、イベントの信頼性が非常に低くなります。

モバイルでは、Chrome と Safari は unload イベント リスナーを使用してページをキャッシュしようとします。これは、モバイルでは unload イベントが常に非常に信頼できないため、破損のリスクが低いためです。Firefox は、unload を使用するページを bfcache の対象外として扱います。ただし、iOS ではすべてのブラウザで WebKit レンダリング エンジンを使用する必要があるため、Safari と同様に動作します。

unload イベントを使用する代わりに、pagehide イベントを使用します。pagehide イベントは、unload イベントが発生するすべてのケースで発生します。また、ページが bfcache に配置されたときにも発生します。

実際に、Lighthouse には no-unload-listeners 監査があり、ページの JavaScript（サードパーティのライブラリを含む）に unload イベント リスナーが追加された場合に警告が表示されます。

bfcache は信頼性が低く、パフォーマンスにも影響するため、Chrome では unload イベントのサポート終了を予定しています。

権限ポリシーを使用して、ページでアンロード ハンドラが使用されないようにする

unload イベント ハンドラを使用していないサイトでは、Chrome 115 の権限ポリシーを使用することで、unload イベント ハンドラが追加されないようにすることができます。

Permission-Policy: unload()

また、サードパーティや拡張機能がアンロード ハンドラを追加し、サイトを bfcache の対象から外すことで、サイトの速度が低下するのを防ぎます。

条件付きでのみ beforeunload リスナーを追加する

beforeunload イベントが発生しても、ページが最新のブラウザの bfcache で bfcache の対象から外れることはありませんが、以前はそうでしたが、今でも信頼性が低くなっていたため、どうしても必要な場合を除き、bfcache の使用は避けてください。

ただし、unload イベントとは異なり、beforeunload には正当な用途があります。たとえば、保存していない変更があることをユーザーに警告する場合、ユーザーがページから移動すると変更内容は失われます。この場合、ユーザーの変更が保存されていない場合にのみ beforeunload リスナーを追加し、保存されていない変更が保存された直後にそれらを削除することをおすすめします。

すべきでないこと
window.addEventListener('beforeunload', (event) => {
  if (pageHasUnsavedChanges()) {
    event.preventDefault();
    return event.returnValue = 'Are you sure you want to exit?';
  }
});
このコードは、beforeunload リスナーを無条件に追加します。
推奨事項
function beforeUnloadListener(event) {
  event.preventDefault();
  return event.returnValue = 'Are you sure you want to exit?';
};

// A function that invokes a callback when the page has unsaved changes.
onPageHasUnsavedChanges(() => {
  window.addEventListener('beforeunload', beforeUnloadListener);
});

// A function that invokes a callback when the page's unsaved changes are resolved.
onAllChangesSaved(() => {
  window.removeEventListener('beforeunload', beforeUnloadListener);
});
このコードは、必要な場合にのみ beforeunload リスナーを追加します（不要な場合は削除します）。

Cache-Control: no-store の使用を最小限に抑える

Cache-Control: no-store は、ウェブサーバーがレスポンスに対して設定できる HTTP ヘッダーで、HTTP キャッシュに保存しないようにブラウザに指示します。ログインが必要なページなど、ユーザーの機密情報を含むリソースに使用されます。

bfcache は HTTP キャッシュではありませんが、Cache-Control: no-store が（サブリソースではなく）ページリソース自体で設定されている場合、ブラウザはそのページを bfcache に保存しないよう選択していました。現在、プライバシーに配慮した方法で Chrome のこの動作を変更する作業が行われていますが、現時点では Cache-Control: no-store を使用しているページは bfcache の対象になりません。

Cache-Control: no-store は、ページの bfcache の適格性を制限するため、なんらかのキャッシュ保存が適切ではない機密情報を含むページでのみ設定してください。

常に最新のコンテンツを提供する必要があり、そのコンテンツに機密情報が含まれていない場合は、Cache-Control: no-cache または Cache-Control: max-age=0 を使用します。これらのディレクティブは、コンテンツを配信する前に再検証するようブラウザに指示します。ページの bfcache の適格性には影響しません。

ページを bfcache から復元する場合、HTTP キャッシュからではなく、メモリから復元されます。そのため、Cache-Control: no-cache や Cache-Control: max-age=0 などのディレクティブは考慮されず、コンテンツがユーザーに表示される前に再検証は行われません。

ただし、bfcache の復元は即時に行われ、ページが bfcache に長時間留まることはないため、コンテンツが古くなる可能性は低いため、ユーザー エクスペリエンスは向上する可能性があります。ただし、コンテンツが分単位で変化する場合は、次のセクションで説明するように、pageshow イベントを使用して更新を取得できます。

bfcache 復元後に古いデータや機密データを更新する

サイトでユーザーの状態（特にユーザーの機密情報）が保持されている場合は、ページを bfcache から復元した後に、そのデータを更新または消去する必要があります。

たとえば、ユーザーが購入手続きページに移動してからショッピング カートを更新した場合、古くなったページが bfcache から復元されると、「戻る」ナビゲーションで古い情報が表示される可能性があります。

もう 1 つのより重大な例として、ユーザーが公共のコンピュータでサイトからログアウトし、次のユーザーが [戻る] ボタンをクリックした場合が挙げられます。これにより、ユーザーがログアウトしたときに消去されたと考えていた個人データが漏洩する可能性があります。

このような状況を回避するには、event.persisted が true の場合に、pageshow イベントの後に常にページを更新することをおすすめします。

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Do any checks and updates to the page
  }
});

コンテンツをその場で更新するのが理想的ですが、変更によっては強制的に完全に再読み込みすることをおすすめします。次のコードは、pageshow イベントにサイト固有の Cookie があるかどうかを確認し、見つからなかった場合は再読み込みを行います。

window.addEventListener('pageshow', (event) => {
  if (event.persisted && !document.cookie.match(/my-cookie)) {
    // Force a reload if the user has logged out.
    location.reload();
  }
});

再読み込みには履歴が残るというメリットがありますが（次に進むことができるため）、リダイレクトのほうが適切な場合もあります。

広告と bfcache の復元

「戻る」または「進む」ナビゲーションのたびに新しい一連の広告を配信するために、bfcache の使用は避けたくなるかもしれません。しかし、そのような行動がパフォーマンスに影響を与えるだけでなく、広告エンゲージメントの向上につながるかどうかは疑問です。クリックに戻ろうとしていた広告が bfcache から復元するのではなく、再読み込みして表示されることにユーザーが気づく場合があります。前提条件を決める前に、このシナリオをテスト（理想的には A/B テスト）することが重要です。

サイトで bfcache による復元で広告を更新する必要がある場合は、event.persisted が true のときに pageshow イベントの広告のみを更新すれば、ページのパフォーマンスに影響を与えずに更新できます。広告プロバイダにご確認ください。ただし、Google Publishing Tag でこれを行う方法の一例をご覧ください。

window.opener の参照を避ける

古いブラウザでは、rel="noopener" を指定せずに target=_blank でリンクから window.open() を使用してページを開いた場合、開始ページは開いたページの window オブジェクトへの参照を持ちます。

null 以外の window.opener 参照があるページは、セキュリティ上のリスクになるだけでなく、bfcache に格納しても安全ではありません。bfcache に入れると、そのページにアクセスしようとするページが破損する恐れがあります。

そのため、window.opener 参照は作成しないことをおすすめします。そのためには、可能な限り rel="noopener" を使用します（現在、これはすべての最新ブラウザでデフォルトになっています）。サイトでウィンドウを開いて window.postMessage() で制御する、または window オブジェクトを直接参照する必要がある場合、開いているウィンドウもオープナーも bfcache の対象になりません。

ユーザーが離れる前に、開いている接続を閉じる

前述したように、ページが bfcache に入ると、スケジュールされたすべての JavaScript タスクが一時停止され、ページがキャッシュから取り出された時点でそれらのタスクが再開されます。

これらのスケジュールされた JavaScript タスクが DOM API または現在のページだけに分離された他の API のみにアクセスする場合、ページがユーザーに表示されないときにこれらのタスクを一時停止しても問題は生じません。

ただし、これらのタスクが、同じオリジンの他のページからもアクセス可能な API（IndexedDB、Web Lock、WebSocket など）に接続されている場合、これらのタスクを一時停止すると他のタブのコードが実行されなくなる可能性があるため、問題が発生する可能性があります。

その結果、一部のブラウザでは、次のような場合にページを bfcache に保存しようとしません。

ページでこれらの API のいずれかを使用している場合は、pagehide イベントまたは freeze イベント中に接続を閉じ、オブザーバーを削除するか切断することを強くおすすめします。これにより、開いている他のタブに影響を及ぼすリスクを冒すことなく、ブラウザはページを安全にキャッシュできます。

その後、ページが bfcache から復元されると、pageshow イベントまたは resume イベント中にそれらの API を再開または再接続できます。

次の例は、pagehide イベント リスナーで開いている接続を閉じて、IndexedDB を使用するページが bfcache の対象であることを確認する方法を示しています。

let dbPromise;
function openDB() {
  if (!dbPromise) {
    dbPromise = new Promise((resolve, reject) => {
      const req = indexedDB.open('my-db', 1);
      req. => req.result.createObjectStore('keyval');
      req. => reject(req.error);
      req. => resolve(req.result);
    });
  }
  return dbPromise;
}

// Close the connection to the database when the user leaves.
window.addEventListener('pagehide', () => {
  if (dbPromise) {
    dbPromise.then(db => db.close());
    dbPromise = null;
  }
});

// Open the connection when the page is loaded or restored from bfcache.
window.addEventListener('pageshow', () => openDB());

ページがキャッシュ可能かどうかをテストする

Chrome DevTools では、ページが bfcache に最適化されているかどうかをテストして確認し、bfcache の対象にならない可能性のある問題を特定できます。

ページをテストするには:

  1. Chrome のページに移動します。
  2. DevTools で、[アプリケーション] -> [バックフォワード キャッシュ] に移動します。
  3. [Run Test] ボタンをクリックします。その後 DevTools は、そのページを離れてから戻って、bfcache からページを復元できるかどうかを判断しようとします。
DevTools のバックフォワード キャッシュ パネル
DevTools の [バックフォワード キャッシュ] パネル

テストが成功すると、パネルに「Restored from back-forward cache」と表示されます。

DevTools でページが bfcache から正常に復元されたと報告される
正常に復元されたページ。

失敗した場合は、その理由がパネルに表示されます。デベロッパーが対処できる理由である場合は、パネルに [Actionable]（対応可能）と表示されます。

DevTools で bfcache からページを復元できないと報告される
bfcache テストの失敗で、対処可能な結果が示されています。

この例では、unload イベント リスナーが使用されているため、ページが bfcache の対象外になっています。これを修正するには、unload から pagehide を使用するように切り替えます。

推奨事項
window.addEventListener('pagehide', ...);
すべきでないこと
window.addEventListener('unload', ...);

Lighthouse 10.0 には、同様のテストを行う bfcache 監査も追加されました。詳しくは、bfcache 監査のドキュメントをご覧ください。

bfcache が分析やパフォーマンス測定に及ぼす影響

解析ツールを使用してサイトへのアクセスを測定している場合、Chrome で bfcache を有効にするユーザーが増えるため、報告されるページビュー数が減少することがあります。

実際、一般的な分析ライブラリの多くは bfcache による復元を新しいページビューとして測定しないため、bfcache を実装している他のブラウザからのページビューは、すでに過小報告されている可能性があります。

bfcache による復元をページビュー数に含めるには、pageshow イベントのリスナーを設定し、persisted プロパティを確認します。

次の例は、Google アナリティクスでこれを行う方法を示しています。他の分析ツールも同様のロジックを使用する可能性があります。

// Send a pageview when the page is first loaded.
gtag('event', 'page_view');

window.addEventListener('pageshow', (event) => {
  // Send another pageview if the page is restored from bfcache.
  if (event.persisted) {
    gtag('event', 'page_view');
  }
});

bfcache ヒット率を測定する

また、bfcache が使用されたかどうかを測定して、bfcache を使用していないページを特定することもできます。そのためには、ページ読み込みのナビゲーション タイプを測定します。

// Send a navigation_type when the page is first loaded.
gtag('event', 'page_view', {
   'navigation_type': performance.getEntriesByType('navigation')[0].type;
});

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // Send another pageview if the page is restored from bfcache.
    gtag('event', 'page_view', {
      'navigation_type': 'back_forward_cache';
    });
  }
});

back_forward ナビゲーションと back_forward_cache ナビゲーションの数を使用して、bfcache のヒット率を計算します。

「戻る」と「進む」ナビゲーションで bfcache が使用されない場合、サイト所有者の管理外にはさまざまな状況があることを理解しておくことが重要です。

  • ユーザーがブラウザを終了して再起動したとき
  • ユーザーがタブを複製したとき
  • ユーザーがタブを閉じて再度開いたとき

一部のブラウザでは元のナビゲーション タイプが保持されるため、戻る/進むナビゲーションではないにもかかわらず、タイプ back_forward が表示される場合があります。

これらの除外がなくても、メモリを節約するために bfcache は一定期間後に破棄されます。

そのため、ウェブサイトの所有者は、すべての back_forward ナビゲーションで bfcache のヒット率が 100% になるとは限りません。ただし、その比率を測定すると、戻る / 進むナビゲーションの多くで bfcache の使用を妨げているページ自体を特定するのに役立ちます。

Chrome チームは NotRestoredReasons API を追加しました。これにより、ページで bfcache が使用されない理由を明らかにし、デベロッパーが bfcache のヒット率を向上させることができます。また、Chrome チームは CrUX にナビゲーション タイプを追加し、bfcache ナビゲーションの数を自分で測定しなくても確認できるようにしました。

パフォーマンスの測定

bfcache は、フィールドで収集されたパフォーマンス指標、特にページの読み込み時間を測定する指標にも悪影響を及ぼすことがあります。

bfcache のナビゲーションでは、新しいページの読み込みを開始するのではなく既存のページを復元するため、bfcache を有効にすると収集されるページ読み込みの合計数は少なくなります。ただし、重要なのは、ページ読み込みが bfcache 復元に置き換えられたことで、データセットで最も高速なページ読み込みである可能性が高いことです。これは、「戻る」ナビゲーションと「進む」ナビゲーションは本質的にリピート アクセスであり、リピート ページの読み込みは初回訪問者のページ読み込みよりも一般的に速いためです（前述の HTTP キャッシュにより）。

その結果、データセットでのページ読み込みが速くなり、分散のスキューが遅くなる可能性があります。ただし、ユーザーが経験するパフォーマンスはおそらく向上したものの、

この問題にはいくつかの方法で対処できます。1 つは、すべてのページ読み込み指標に、それぞれのナビゲーション タイプ（navigate、reload、back_forward、prerender）でアノテーションを付ける方法です。これにより、全体的な分布が負に偏っている場合でも、これらのナビゲーション タイプ内でのパフォーマンスを引き続きモニタリングできます。最初のバイトまでの時間（TTFB）など、ユーザー中心ではないページ読み込み指標には、この方法をおすすめします。

Core Web Vitals などのユーザー中心の指標については、ユーザー エクスペリエンスをより正確に表す値を報告するのが適切です。

Core Web Vitals への影響

Core Web Vitals では、ウェブページのユーザー エクスペリエンスをさまざまな項目（読み込み速度、インタラクティブ性、視覚的な安定性）で測定します。bfcache による復元ではページ全体を読み込むよりもナビゲーションが速いため、Core Web Vitals の指標にこれを反映することが重要です。結局のところ、ユーザーは bfcache が有効かどうかを気にする必要はありません。単にナビゲーションが速いということだけ気にしているだけです。

Core Web Vitals の指標を収集して報告するツール（Chrome ユーザー エクスペリエンス レポートなど）は、bfcache による復元をデータセット内の個別のページアクセスとして扱います。また、bfcache による復元後にこれらの指標を測定するための専用のウェブ パフォーマンス API はありませんが、既存のウェブ API を使用して値を近似できます。

  • Largest Contentful Paint（LCP）では、pageshow イベントのタイムスタンプと次にペイントされるフレームのタイムスタンプの差分を使用します。これは、フレーム内のすべての要素が同時にペイントされるためです。bfcache 復元の場合、LCP と FCP は同じです。
  • [Interaction to Next Paint（INP）] では、既存の Performance Observer を引き続き使用し、現在の INP 値を 0 にリセットします。
  • Cumulative Layout Shift（CLS）では、既存の Performance Observer を引き続き使用し、現在の CLS 値を 0 にリセットします。

bfcache が各指標に与える影響について詳しくは、Core Web Vitals の個別の指標に関するガイドページをご覧ください。これらの指標の bfcache バージョンを実装する方法の具体例については、PR が web-vitals JS ライブラリに追加するをご覧ください。

web-vitals JavaScript ライブラリは、レポートする指標で bfcache 復元をサポートしています。

参考情報