The header that used to break back navigation no longer does

Chrome finished rolling out back-forward cache eligibility for pages served with the no-store cache directive in April 2025. Enterprise CMS platforms that set that header across the entire site, which is most of them, got instant back navigation without changing a line of code.

If your last performance audit told you no-store was blocking the back-forward cache, that finding is now out of date, and the remaining blockers are different ones worth knowing.

What the back-forward cache is and why it is worth this much

When a user navigates away, the browser can keep the whole page in memory, JavaScript heap and all, rather than tearing it down. Press back and the page is restored exactly as it was, scroll position included, in roughly 100 to 200 milliseconds. No network request, no re-render, no re-running scripts.

Back navigation is a huge share of real browsing. Someone opens a service page from your listing, reads, goes back, opens another. On a site where back is instant, that pattern feels like an app. On a site where back is a full reload, people stop doing it, and your pages per session quietly falls.

It is also the cheapest performance win available, because you do not build anything. You remove blockers.

What changed with the no-store directive

The no-store cache directive used to disqualify a page outright, on the reasoning that a page the server said should never be stored should not be held in memory either. That is a defensible position and it was also enormously expensive, because enterprise platforms apply it globally to avoid ever serving stale personalised content.

Chrome now allows it, with an eviction rule: if the relevant cookies change while the page sits in the cache, the entry is discarded and a real navigation happens. That is the correct compromise. A user who logs out in another tab does not get a cached logged-in page handed back to them.

The practical effect for a large corporate site is that back navigation got several times faster on a change nobody made.

The blockers that remain

These are the ones to actually go and check.

The unload event handler. A page with an unload listener is not eligible, full stop, and unload handlers are everywhere because a decade of analytics and session tools used them to send final beacons. The replacement is pagehide, plus the Beacon API or fetch with keepalive. This is now the most common blocker on established sites, and it is usually inherited from a third-party script rather than written by your team.

Open connections at the wrong moment. An in-flight indexed database transaction, or an open WebSocket doing something the browser cannot safely pause, can block it.

Certain header combinations. Some combinations involving the no-store directive still disqualify, so verify rather than assume.

Permission-related state. A page holding certain device permissions is not eligible.

How to check in five minutes

Chrome DevTools has this built in and almost nobody uses it. Open DevTools, go to the Application panel, find the back-forward cache section, and run the test. Chrome navigates away and back, then tells you whether the page was restored, and if not, gives you the specific reason with the blocking API named.

Run it on your five highest traffic templates. The reasons are precise enough to hand straight to a developer, or to a vendor if the blocker is in their script.

Then check the field. The hit rate is reportable through the web-vitals library, and Chrome's own data shows the gap between what a site could get and what it does get is usually large.

The third-party conversation this starts

If the blocker turns out to be a vendor script, you now have a specific, evidenced request rather than a vague complaint. Telling a vendor that their tag registers an unload handler, which makes every page on our site ineligible for the back-forward cache, and here is the DevTools output, is a request that gets actioned. Telling them their tag is slowing our site down is not.

That is worth doing across your whole third-party stack once a year regardless. Chat widgets, session recorders, consent platforms, personalisation tools and older analytics tags are the usual sources, and the cost is invisible until someone measures it.

What it does not do

It does not help first visits, and it does not affect the Core Web Vitals of a fresh page load. It affects the restored navigation, which Chrome reports separately.

So this will not fix a failing LCP. It will make your site feel materially faster to the people already reading it, and it will show up in engagement metrics before it shows up in a performance report.

A header that used to cost you every back button on the site stopped costing you anything, and most sites have not noticed.