Disconnect WebSockets on BFCache Entry

at a glance

why it exists

The back/forward cache (BFCache) stores a page's full live state in memory so that back-button and forward-button navigation is nearly instant. Until Chrome 149, any page with an active WebSocket connection was disqualified from BFCache — the browser couldn't safely freeze a live connection. Popular web apps like Notion, Figma, and Slack Web all keep persistent WebSocket connections, so BFCache was effectively unavailable for them, hurting navigation performance for millions of users.

Chrome 149 resolves the incompatibility by closing WebSocket connections when the page enters BFCache rather than blocking caching entirely. Well-written apps already handle the close event to reconnect on unexpected disconnections (network drops, server restarts). Those apps get BFCache for free.

what changes

example

Reconnect on BFCache restore

let ws;

function connect() {
  ws = new WebSocket("wss://example.com/live");
  ws.addEventListener("message", handleMessage);
  ws.addEventListener("close", () => {
    // Handles network drops, server restarts, AND BFCache entry.
    // Schedule a reconnect (with back-off in production).
    setTimeout(connect, 1000);
  });
}

// Initial connection.
connect();

// When the page is restored from BFCache, re-establish if close
// handler hasn't already scheduled a reconnect.
window.addEventListener("pageshow", (event) => {
  if (event.persisted && ws.readyState !== WebSocket.OPEN) {
    connect();
  }
});

Check BFCache eligibility in DevTools

// Chrome DevTools: Application → Back/Forward Cache → Test.
// A page with an open WebSocket now shows as BFCache-eligible.
// Previously it listed "WebSocket" in the blocking-reasons list.

compatibility notes

browser support

see also

• MDN: Page Lifecycle API — BFCache
• MDN: WebSockets API
• web.dev: Back/forward cache (bfcache)
• WHATWG HTML PR #12349 — the normative spec change
• chrome-platform-showcase: BFCache WebSocket demos