Back/Forward Cache（bfcache）の保存条件と復元

なぜ bfcache を正確に理解する必要があるのか

「戻る」ボタンを押したとき、ページがネットワーク往復もスクロール位置のリセットもなく一瞬で出てくることがあります。これを実現しているのが Back/Forward Cache（bfcache、往復キャッシュ） です。通常のナビゲーションはページを破棄して次のページを一から組み立てますが、bfcache はページを破棄せずメモリに凍結しておき、戻る/進むのときにその凍結状態をそのまま蘇らせます。問題は、この凍結が条件を1つでも満たさないと働かない点です。条件は仕様アルゴリズムとして定義されており、知らずに unload を登録したり接続を開きっぱなしにすると bfcache が黙って無効化され、戻るが遅くなります。本記事はその保存条件と復元イベントを内部レベルで解きほぐします。

凍結とは何か：破棄しないという発想

通常、別ページへ遷移すると、現在のページのドキュメントは破棄され、JS の実行コンテキスト・DOM ツリー・タイマー・ヒープがすべて解放されます。戻ってきたときは再度 HTML を取得しパースし直すため、最良でもネットワーク往復＋再構築のコストがかかります。

bfcache はこの破棄を行いません。遷移時にページ全体を frozen（凍結） 状態にして、次の構成要素をメモリ上にそのまま保持します。

凍結されたページは JS が走らない静止状態に置かれます。タイマーのコールバックも、進行中の Promise の続きも、復元されるまで保留されます。だからこそ復元は速い――ネットワークも再パースもなく、保留していた実行を再開してスクロール位置を当てるだけで表示が完了するため、戻る操作は典型的に数十ミリ秒で終わります。この破棄しない設計が、通常ナビゲーションとの決定的な違いです。

何が bfcache を阻害するのか

ブラウザはページを凍結できるかどうかを、遷移の瞬間に適格性（eligibility）チェックで判定します。1つでも該当すると凍結を諦め、通常どおりページを破棄します。代表的な阻害要因は次のとおりです。

最も多い落とし穴が unload イベントです。歴史的に「離脱時にデータ送信」目的で使われてきましたが、unload の存在自体が bfcache を無効化します。unload はそもそも信頼性が低く（モバイルでは発火しないことがある）、代替として pagehide や visibilitychange を使うのが現在の定石です。beforeunload も一部ブラウザで阻害要因となるため、登録は遷移の確認が本当に必要な場面に限定します。

開いた接続（WebSocket や進行中の fetch、IndexedDB トランザクション）は、凍結中に維持できないため阻害要因になります。これらは後述の pagehide で能動的に閉じ、復元時に張り直す設計にすれば、凍結を妨げずに済みます。

pagehide / pageshow：凍結と復元のフック

bfcache を扱う鍵は、ライフサイクルイベントを load/unload ではなく pageshow/pagehide で捉えることです。両イベントは event.persisted というブール値を持ち、これが凍結が絡んだ遷移かどうかを示します。

復元時、load イベントは発火しません（ドキュメントは再ロードされていないため）。代わりに pageshow が event.persisted === true で発火します。したがって「ページ表示のたびに走らせたい初期化」は load だけでなく pageshow にも置く必要があります。逆に離脱時の後始末は、unload ではなく pagehide に書きます。

// 復元の検知：bfcache から戻ったときだけ true
window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    // 凍結中に止まっていた時計や、古くなったデータの再取得を行う
    refreshTimestampClock();
    revalidateStaleData();
  }
});

// 離脱の検知：unload ではなく pagehide を使う（unload は bfcache を阻害する）
window.addEventListener('pagehide', (event) => {
  if (event.persisted) {
    // これから凍結される：接続を閉じ、復元時に張り直せる状態にする
    closeWebSocket();
  } else {
    // 完全に破棄される：最後のデータ送信はここで（sendBeacon が安全）
    navigator.sendBeacon('/log', collectMetrics());
  }
});

pagehide の event.persisted を見れば、凍結されようとしているのか（true）／完全に破棄されるのか（false） を区別できます。凍結なら接続だけ閉じて状態は残し、破棄なら最終ログを送る、という分岐が書けます。離脱ログの送信には、凍結・破棄のどちらでも確実に飛ぶ navigator.sendBeacon() が適します。

凍結中の JS と復元後の状態整合

凍結されたページの JS は実行が一時停止します。setTimeout のコールバックは凍結時刻で止まり、復元されると残り時間から再開されるわけではなく、止まっていた分だけ「時間が飛んだ」ように見えます。タイマーやアニメーションの内部状態は イベントループ のタスクキューごと保留され、resume／pageshow のタイミングでまとめて処理が再開されます。

ここで生じる実務上の問題が state の陳腐化 です。凍結中に時間が経つと、表示中のデータが古くなります。たとえば「最終更新: ○分前」のような相対時刻、認証トークンの有効期限、株価やカートの在庫数などは、凍結前の値のまま復元されます。だからこそ pageshow で event.persisted を見て、復元時にだけ必要なデータを再取得・再計算するのが定石です。すべてを無条件に再取得すると bfcache の速度メリットを打ち消すため、「古くなって困るものだけ」を選んで更新します。

計測と検証

bfcache が効いているかは、ブラウザの開発者ツールで判定できます。Chrome では DevTools の Application パネルに「Back/forward cache」のテスト機能があり、実際に凍結を試みて非適格なら理由（どの要因で弾かれたか）を列挙してくれます。unload 由来か no-store 由来かが具体的に分かるため、原因の切り分けが速くなります。

bfcache はナビゲーションの体感を大きく左右するため、Core Web Vitals の文脈でも重要です。復元は新規ロードではないため、戻る操作で LCP 等が「速い側」に倒れます。逆に bfcache が効かないと戻るのたびにフルロードのコストが乗り、フィールドデータの数値を悪化させます。

まとめ