Robust users of WebSocket use the "close" event to detect disconnections and trigger reconnect attempts. These should continue to work as-is.
Pages that don't have code to handle unexpected disconnections will fail to reconnect when restored from the BFCache, forcing users to reload manually. In my opinion this is acceptable because pages that don't handle unexpected disconnections are already unreliable. On Fri, 17 Apr 2026 at 20:08, Yoav Weiss (@Shopify) <[email protected]> wrote: > What should we expect the web exposed impact of this change to be? Am I > correct to assume that pages that don't reconnect on pageshow will have > some of their functionality broken? > > On Fri, 17 Apr 2026, 12:17 Chromestatus, <[email protected]> > wrote: > >> *Contact emails* >> [email protected], [email protected] >> >> *Specification* >> https://github.com/whatwg/html/pull/12349 >> >> *Summary* >> Active WebSocket connections no longer prevent a page from entering the >> Back/Forward Cache (BFCache). By closing connections on BFCache entry >> instead of marking the document as ineligible, the browser allows pages >> with active websockets to be stored and restored. >> >> *Blink component* >> Blink>Network>WebSockets >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebSockets%22> >> >> *Web Feature ID* >> *No information provided* >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> *No information provided* >> >> *Gecko*: No signal ( >> https://github.com/mozilla/standards-positions/issues/1390) >> >> *WebKit*: Shipped/Shipping ( >> https://github.com/WebKit/standards-positions/issues/648) >> >> *Web developers*: Positive ( >> https://www.linkedin.com/feed/update/urn:li:activity:7376981348709756928?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7376981348709756928%2C7377217740341747712%29&replyUrn=urn%3Ali%3Acomment%3A%28activity%3A7376981348709756928%2C7377954189664129024%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287377217740341747712%2Curn%3Ali%3Aactivity%3A7376981348709756928%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287377954189664129024%2Curn%3Ali%3Aactivity%3A7376981348709756928%29) >> In >> this post, Wix explains how BFCache helped raise their global Core Web >> Vitals pass rate from 61% to 75%. They identified WebSocket connections >> from chat widgets as a key blocker. This reflects a common challenge where >> developers lack control over WebSockets in third-party scripts, and >> feedback on this effort has been very positive. >> >> *Other signals*: >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? >> *No information provided* >> >> >> *Debuggability* >> *No information provided* >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> >> https://wpt.fyi/results/websockets/back-forward-cache-closes-open-websocket-connection.tentative.window.html >> This new WPTs have been upstreamed, but results may not yet appear on >> wpt.fyi. We have an existing test which verifies that active WebSockets >> block BFCache entry: >> https://wpt.fyi/results/websockets/back-forward-cache-with-open-websocket-connection.window.html?label=experimental&label=master&aligned. >> The existing WPT will eventually be replaced by the new WPT. >> >> >> >> *Tracking bug* >> https://g-issues.chromium.org/issues/467838624 >> >> *Estimated milestones* >> Shipping on desktop 148 >> Shipping on Android 148 >> Shipping on WebView 148 >> Shipping on iOS 148 >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5068439115923456 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69e208a3.710a0220.254d62.0009.GAE%40google.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69e208a3.710a0220.254d62.0009.GAE%40google.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKA8fP5QuOE52cVhpRSX0BDSb3NkjyjMt%3DQBTWXEtYicg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKA8fP5QuOE52cVhpRSX0BDSb3NkjyjMt%3DQBTWXEtYicg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAC_ixdwjKMcSu6mZtC7JRtBwmVz5D0Kqxa0%3DGC5iLvtN4T4TbQ%40mail.gmail.com.
