v149 · Navigation · BFCache
BFCache State Audit
Compare which types of state are preserved, lost, or reset when a page enters and exits the back/forward cache. Chrome 149's key change: WebSocket connections, which used to block BFCache, now close gracefully on entry — letting the page cache while requiring a reconnect on restore.
WebSocket connection
Before 149:Blocks BFCache
Chrome 149+:Closed gracefully, BFCache allowed
On restore:Must reconnect in pageshow handler
Not connected
localStorage / sessionStorage
BFCache entry:Preserved (snapshotted)
On restore:Available, reads current values
Note:Storage events from other tabs fire on restore
✓ No action needed — always preserved
JavaScript variables / DOM state
BFCache entry:Frozen in memory (exact snapshot)
On restore:Restored to exact state
DOM:Scroll position, form state, focus all preserved
✓ This is the point of BFCache
setTimeout / setInterval
BFCache entry:Timers frozen (don't fire)
On restore:Timers resume — may fire immediately if overdue
Advice:Clear intervals in pagehide, restart in pageshow
⚠ Timers need explicit management
fetch() / XMLHttpRequest in-flight
BFCache entry:In-flight requests aborted
On restore:Requests must be re-issued
Note:Completed responses are preserved in memory
✗ In-flight requests are lost
IndexedDB transactions
BFCache entry:Open transactions block BFCache
Advice:Commit or abort transactions on pagehide
On restore:Re-open transactions as needed
✗ Open transactions block BFCache
PAGE STATE: LIVE (active)
// Events will appear here as you run the page lifecycle drill…
see also
- Connection Lifecycle Observer — WebSocket events through BFCache
- Reconnect on Restore — reconnect pattern implementation
- Navigation Walkthrough — step through BFCache navigation
implementation reference
Need the exact API surface, compatibility boundaries, errors, lifecycle, and source links? Read the matching gendn reference ↗