Web-Facing Change PSA: Disconnect WebSockets on BFCache entry

[Chromestatus]

Contact emails

anna...@google.com, fer...@google.com

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

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?

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.

[Yoav Weiss (@Shopify)]

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?

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/69e208a3.710a0220.254d62.0009.GAE%40google.com.

[Adam Rice]

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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKA8fP5QuOE52cVhpRSX0BDSb3NkjyjMt%3DQBTWXEtYicg%40mail.gmail.com.

[Gilberto Cocchi]

Hello everyone, I've tested most of the most used WebSocket scripts on the web (identified via HTTP Archive and other methods) and, as Adam suggested, I noted that the vast majority already use onError handlers to restart the WebSocket Connection (very few use pageshow etc).

By number of origins, WebSocket is mainly used by 3P Scripts for Live Chat / Customer Support widgets or AI Chat apps.

In the case of 3Ps, developers have no eligibility for bfcache for something outside of their control (most Live Chat widgets initialize the connection before any interaction with the widget).

If I am not mistaken, Safari is already handling WebSocket this way (connection somehow closes and WebSocket users rely on onError or pageshow to restart connection).

--

gTech Up

Gilberto Cocchi Senior Partner Engineer gTech Chrome gilb...@google.com

Google Italy | Via Federico Confalonieri 4 | Porta Nuova Isola | Building C | Milan 20124

Registered in Milan, Italy

This email may be confidential and privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it has gone to the wrong person.

The above terms reflect a potential business arrangement, are provided solely as a basis for further discussion, and are not intended to be and do not constitute a legally binding obligation. No legally binding obligations will be created, implied, or inferred until an agreement in final form is executed in writing by all parties involved.