Proposed changes:

First of all, this prevents Jetpack from sending redundant "nocache" headers which are already being sent by nocache_headers(). The no-store directive was added by default as of WordPress 6.3 via Core-21938, and Jetpack now requires WP 6.7. This removes/deprecates code introduced in #9010 and #23146. The redundancy can be seen by looking at the duplicated no-store in the Cache-Control response header:

Cache-Control: no-cache, must-revalidate, max-age=0, no-store, private, no-store

Secondly, this PR allows plugins to omit the no-store directive to prevent breaking bfcache (back/forward cache) to enable instant history navigations. Plugins can do this via the nocache_headers filter in core. For example, I've been working on No-cache BFCache plugin which allows a user to opt in to bfcache by checking the "Remember Me" checkbox. This is a feature plugin for Core-63636 (Enable instant page navigations from browser history via bfcache when sending "nocache" headers) which I hope to land in WP 6.9. However, when Jetpack is active this is blocked due to the no-store which it adds. See the Web.dev bfcache article section on minimizing use of Cache-Control: no-store.

Demo Videos

Compare navigating back/forward without bfcache and with bfcache, in the first video without bfcache I try navigating back and forward as soon as the page fully loads. In the second video with bfcache, navigation back and forward is instant and because of that the network log shows as empty, and I end the video with trying to go back and forward as fast as I possibly can to show how instant the page load is:

See also woocommerce/woocommerce#58445 for a similar removal of no-store from WooCommerce and a demo video of how this can improve the user's browsing experience. If the original desire for introducing no-store was to ensure that the no stale data is shown on the Jetpack settings screens, then the better way to achieve this is to add a pageshow event handler that checks the event object's persisted property to see if it is true, and in that case fetch the latest data. WooCommerce is already doing this to ensure the cart data is as fresh as possible when pages are restored from bfcache.

Aside 1: In Chrome, the WebSocket opened by the Notifications module currently also disables bfcache. However, this won't break bfcache in a future version of Chrome according to DevTools. In the meantime, bfcache can be enabled in the admin when Jetpack is active by deactivating the Notifications moule in Jetpack settings (on /wp-admin/admin.php?page=jetpack_modules) and by having this PR applied which removes Cache-Control: no-store.

Aside 2: The Akismet screen breaks bfcache due to an unload event listener served from an frame at https://tools.akismet.com/1.0/snapshot.php. The unload event should never be used. Its use was removed from WordPress in Core-55491 for WP 6.4, so it should be removed from the Akismet service as well.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

No.

Testing instructions:

1. Navigate to the Jetpack screens and ensure that Cache-Control: no-store is still being sent as expected.

Closes HOG-232