Notifications: WebSocket connection blocks pages from back/forward cache (bfcache) eligibility

[westonruter]

Impacted plugin

Jetpack

Quick summary

When the Notifications module is active, a WebSocket is open on every page when a user is logged-in and the Admin Bar is showing. As noted in the web.dev article on Back/forward cache, such WebSocket connections make pages ineligible for bfcache. This means that users cannot take advantage of instant back/forward navigations. This was previously in #44322.

When Jetpack's open WebSocket is on the page, the Back/forward cache panel in Chrome DevTools reports the following:

This connection is opened via an iframe'd page located at https://public-api.wordpress.com/wp-admin/rest-proxy/?v=2.0

To fix this issue, the aforementioned article advises to Close open connections before the user navigates away.

Guidance, with code samples, was also recently added to MDN: Working with the bfcache.

Steps to reproduce

1. Enable the Notifications module
2. Navigate from the WP Admin dashboard to another admin screen, and then try navigating back.
3. Notice that the navigation is not instant, even when you have the No-cache BFCache plugin active (soon to be renamed “Instant Back/Forward”). Confirm this via a bfcache test in Chrome DevTools.

Site owner impact

More than 60% of the total website/platform users

Severity

Minor

What other impact(s) does this issue have?

No revenue impact

If a workaround is available, please outline it here.

As advised in the FAQ for the No-cache BFCache plugin, a workaround is to just disable the Notifications module.

Platform (Simple and/or Atomic)

Self-hosted