Enable instant page navigations from browser history via bfcache when sending "nocache" headers

Trac ticket: https://core.trac.wordpress.org/ticket/63636

I've also formulated the patch in a standalone plugin: ​https://github.com/westonruter/nocache-bfcache

I just learned of the ​Clear-Site-Data header as well.

Upon logging out, the following header could get sent:

Clear-Site-Data: "cache"

According to MDN, it says this "might" clear out the bfcache "depending on the browser". In testing with Chrome, however, this doesn't seem to work. So the JavaScript-based client-side bfcache invalidation still seems needed.

This remains an ​open question in w3c/webappsec-clear-site-data. There's another ​executionContexts directive which seems to have been intended for this purpose, but it is not (any longer) ​implemented by browsers.

I've published a feature plugin to the dotorg directory: ​https://wordpress.org/plugins/nocache-bfcache/

Blog post with writeup: ​https://weston.ruter.net/2025/07/23/instant-back-forward-navigations-in-wordpress/

1) Since the function is called "wp_get_nocache_headers()" I'd expect that there should be absolutely no caching including no bfcache be happening. This is why "no-store" should stay included.

Instead, maybe create a "wp_get_only_bfcache_headers()" (or whatever makes sense) which excludes "no-store" and uses "private" only.

2) In an ideal world it's +100 from me :-)
However:
The problem with those headers is always that proxy caches change if/which directives they adhere to and how.

Theoretically, you're right that according to ​https://datatracker.ietf.org/doc/html/rfc7234 just setting "private" without no-store should be enough to ensure it's not stored in any proxy caches.

Unfortunately, it is not in practice:
​https://developers.cloudflare.com/cache/concepts/cache-control/#conditions

Cache-Control returned to eyeball does not include private.

This means that suddenly it's Cache-Control without no-store and without private.
Now it might happen that max-age is ignored too e.g. due to account limitations at the Edge (e.g. ​https://developers.cloudflare.com/cache/concepts/cache-control/#expiration) and you'll suddenly end up serving private, non-cacheable data to everybody.
Fyi: what's in Cloudflare's docs and what is actually happening is often 2 very different things that may also change without any notice from my experience working closely with Cloudflare's caches for a decade now.

While I wish this was a theoretical assumption only, it's been something that has been exploited a couple years back with some cache plugins/CDNs.

Since WP is used behind all kinds of set-ups, the only absolutely safe way is to actually always use both - no-store, private - for pages that are at risk of replay attacks (especially since WP's nonce, isn't a real nonce that can only be used once) and/or pages that contain private data.

3) the bfcache introduces a huge potential for data loss for data that can be used by multiple users (= anything in wp-admin)
e.g. user A opens page 123, then navigates to page 456.
User B changes the title of 123 from "Hello" to "World"
User A clicks the browser back button - it will show title 123 "Hello" - if the user now clicks "Update", it will restore the old title again.
This is bc ​https://web.dev/articles/bfcache

Note that when a page is restored from bfcache, it is restored from memory, not from the HTTP cache. As a result, directives like Cache-Control: no-cache or Cache-Control: max-age=0 are not taken into account, and no revalidation occurs before the content is displayed to the user.

Fyi Chrome is implementing this natively: ​https://developer.chrome.com/docs/web-platform/bfcache-ccns
Also see ​https://github.com/whatwg/html/issues/7189

@kkmuffme Sorry for the delay in replying to you.

Replying to kkmuffme:

1) Since the function is called "wp_get_nocache_headers()" I'd expect that there should be absolutely no caching including no bfcache be happening. This is why "no-store" should stay included.

Except for most of this function's existence, from 2.8.0 until 6.3.0, it didn't include no-store. The function has "nocache" in its name which to me implies the no-cache directive.

2) In an ideal world it's +100 from me :-)
However:
The problem with those headers is always that proxy caches change if/which directives they adhere to and how.

I don't fully understand everything you've outlined here. But I will note that the Cloudflare docs there say: "private — Indicates the response message is intended for a single user, such as a browser cache, and must not be stored by a shared cache like Cloudflare or a corporate proxy."

I don't understand the the Cloudflare docs there on the conditions. When it says “Browser Cache TTL is set” is this referring to the max-age directive? It says if Origin Cache Control is disabled, “Cache-Control returned to eyeball does not include private.” (Aside: Strange to mention “eyeball” 👁️ and not “the client”.) Is a solution here then to make sure the Cache-Control response header does not have max-age?

3) the bfcache introduces a huge potential for data loss for data that can be used by multiple users (= anything in wp-admin)

Yes, this is a good callout. Nevertheless, the lack of bfcache also introduces a huge potential for data loss for all users as well, if they navigate away from a page without having saved a change, for example. But you're also right that there needs to be better accounting for updating stale data. I opened an issue for this a couple months ago: ​https://github.com/westonruter/nocache-bfcache/issues/25

I will say, however, that post locking should specifically deal with the scenario you're talking about.

Fyi Chrome is implementing this natively: ​https://developer.chrome.com/docs/web-platform/bfcache-ccns
Also see ​https://github.com/whatwg/html/issues/7189

Yes, but unfortunately cookie changes happen often, especially client-side via JS, which means this doesn't apply. And this is Chrome only.

And the Chrome docs there still say: “Best practice remains to minimize use of Cache-Control: no-store rather than depend on these heuristics.”

Another common reason I see bfcache being blocked is JsNetworkRequestReceivedCacheControlNoStoreResource, where JavaScript on a page makes a request to a resource served with the no-store directive (e.g. REST API or admin-ajax). This happens everywhere in the wp-admin.

Ideally the pageshow event wouldn't need to be relied on to use JS to invalidate pages from bfcache. While this works, it is somewhat of a hack, and there remains a possible split-millisecond in which a previously-authenticated page can appear prior to the pageshow event handler detecting the authentication state change and triggering a reload.

There's also an ​issue I discovered when using a service worker to serve pages with a NetworkFirst strategy, where a page gets served from cache if the network doesn't respond before a timeout occurs. This can result in pages stored in Cache by the service worker which have stale bfcache session token, and then every navigation which returns such a page in cache will immediately reload once served from cache. Not ideal.

The correct solution to protecting privacy is invaliding pages from bfcache using the Clear-Site-Data: "cache" response header, as mentioned above. The benefit here is that there is no JavaScript involved at all. See also the ​feature plugin issue I created for this.

This header is ​well supported by browsers. However, there is currently a bug in Chromium (​40233601) which causes page responses sent with this header to be very slow. I think this should be a blocker preventing this from moving forward until it is fixed.

Punting due to my previous comment about Clear-Site-Data: "cache" not being ready yet in Chrome.