Disconnect WebSockets on BFCache entry

concepts

1. Connection Lifecycle Observer

   Open a WebSocket, watch the event stream as the page enters and exits BFCache. See pagehide, the automatic close, then pageshow — with a new connection ready to reconnect.

   Live API WebSocket BFCache

2. BFCache Eligibility Checker

   Inspect the page's BFCache eligibility live. Shows how an open WebSocket connection used to block BFCache entry and how Chrome 149 handles it by closing the connection gracefully instead.

   Interactive Performance

3. Reconnect on Restore

   Implement and visualise the correct reconnect pattern: open a backend WebSocket, run a BFCache freeze/restore drill, and watch the pageshow(persisted:true) handler automatically re-establish the connection.

4. State Audit

   A six-card audit comparing what state survives a BFCache freeze/restore cycle — WebSocket connections, localStorage, in-memory JS variables, pending timeouts, in-flight fetches, and IndexedDB transactions. Connect a live WebSocket and run the freeze/restore drill to see Chrome 149's graceful close in action.

   Live API BFCache State management

5. Navigation Walkthrough

   Step through a full back-navigation cycle in two modes: pre-Chrome 149 (WebSocket blocks BFCache, full page reload required) and Chrome 149+ (WebSocket closed gracefully, instant restore). See timing differences, BFCache hit/miss stats, and per-step annotations explaining exactly which rules apply.

   Interactive Navigation Performance

6. Heartbeat Recovery

   WebSocket clients commonly send periodic ping/keepalive heartbeats. On BFCache freeze, Chrome 149 closes the socket and the heartbeat timer must be cancelled — otherwise restored pages send pings to a dead socket. Simulate a freeze/restore cycle with two handler modes: the correct pattern (cancel on freeze, reconnect on restore) and the buggy pattern (leaves interval running). Counts dead-socket heartbeats and missed pongs in real time.

why it shipped

Before Chrome 149, any page with an open WebSocket connection was ineligible for the back/forward cache — BFCache. This meant every tab running a realtime app (collaborative editors, live dashboards, stock tickers) had to do a full page reload on back-navigation, burning network bandwidth and adding hundreds of milliseconds of latency. The fix is clean: on pagehide with persisted: true, Chrome closes open WebSocket connections instead of blocking the cache entry. On pageshow (restore), the page can detect it was restored and open a fresh connection. This aligns with the long-standing behaviour for other APIs like EventSource and completes the BFCache story for modern web apps.

references

• ChromeStatus entry
• Chrome Developers — Back/forward cache
• web.dev — Back/forward cache
• Web Platform Tests