The Cache You Didn’t Know You Needed

At the tail end of 2021, Chrome finally joined Safari and Firefox in shipping support for the Back/Forward Cache (bfcache). While Chrome was late to the party, its arrival matters: Chrome is the most widely used browser, and it also feeds the Core Web Vitals data that influences search rankings. The roll-out has already produced measurable improvements, and all Chromium-based browsers — Edge, Opera, Brave and others — inherit the functionality too.

bfcache is a special cache that stores a complete snapshot of the page, including its fully rendered state and JavaScript heap. When a user navigates away and then returns via the back or forward button, the browser restores that snapshot instead of reloading the page from scratch. For common browsing patterns — returning to a home page after reading an article, hopping between search results, or moving back and forth across sites — this makes the return almost instantaneous.

Why the HTTP Cache Isn’t Enough

The HTTP cache has long been the standard performance lever: store copies of downloaded resources on disk and reuse them on subsequent visits. That saves network round trips, but it doesn’t eliminate the entire rendering pipeline. Even with every asset served from cache, the browser still has to parse HTML, fetch and parse CSS, execute JavaScript, decode images and lay out the page. The HTTP cache can make a repeat view faster, but not instant.

WebPageTest is one of the few tools that actually exercises a primed HTTP cache with a repeat-view test. The repeat view is faster than the initial load, but it’s still not a true representation of real-world navigation, where the cache may only be partially primed depending on where the user came from.

A quick manual test makes the difference tangible. Load a home page in a tab, then open it again in a new tab. The second load uses the primed HTTP cache and should feel faster. Then click through to an article and hit the back button. That return is restored from bfcache and feels essentially instant. The contrast becomes far more obvious on a slow mobile connection or a heavier site. Chrome also lets you disable bfcache at chrome://flags/#back-forward-cache for direct experimentation.

What Makes bfcache Faster

bfcache operates on a different principle from the HTTP cache. Instead of storing the individual resources needed to build a page, it stores the page itself, in memory, exactly as the user left it. The user returns to the prior state rather than having the browser reconstruct it.

That in-memory storage provides a speed advantage over the disk-based HTTP cache. Reading from memory is faster than reading from disk — which itself is faster than hitting the network, though the gap is not always as large as you might expect.

There is another subtlety. Many sites refuse to cache the main HTML document, precisely so users receive fresh content on each navigation. Subresources can handle cache expiry through versioned URLs, but the main document URL cannot change. bfcache sidesteps this restriction entirely: it’s restoring a page, not reloading one. So even pages with uncacheable HTML can be restored instantly. Chrome continues to refine its handling in this area, but Safari has had this capability for a while.

The Core Web Vitals Impact

The effect of bfcache is not just theoretical. The Core Web Vitals Technology Report showed unexplained jumps in January 2022 metrics for several e-commerce platforms, with percentage-point improvements ranging from 5% to 18% for origins achieving good CWV scores. Annie Sullivan from the Chrome team confirmed the cause: bfcache restorations skip all the layout shift that normally happens during a page load, producing major improvements in Cumulative Layout Shift (CLS).

For Chrome’s measurement purposes, a bfcache restore still counts as a page navigation. The restored page is faster and more stable, and these events are included in the Core Web Vitals data as additional page views. The same is not true for many third-party analytics tools, however. If they do not explicitly track bfcache restores, those rapid repeat visits vanish from the reported data. The result can be a paradoxical drop in measured traffic and a slower-looking average load time, even as real users see faster experiences. Any site monitoring its performance needs to make sure its analytics setup accounts for bfcache restores.

Why Your Site Might Not Be Getting The Boost

The Back/Forward Cache is not a free win for every site. There are a number of conditions that can make a page ineligible, and some of them stem from other performance techniques that are now working against you.

The most common blocker is the unload event listener. Many pages register this to run clean-up tasks under the assumption that the user is done with the page. That assumption breaks when the page is restored from the cache. This event has long been considered unreliable — it may not fire if the browser crashes or is killed in the background — but the Back/Forward Cache gives a more concrete reason to avoid it: browsers will not cache your page if it or any of its resources uses one.

Other surprising blockers include:

  • Unload listeners for analytics: Some Real User Monitoring tools still rely on unload to log end-of-page data. Better alternatives like pagehide and freeze are now available and are cache-compatible.
  • Dedicated workers: Offloading work to a dedicated worker currently makes a page ineligible, though a fix for this is reportedly in progress.
  • App Install Banners: Sites that prompt for installation (such as PWAs) are also blocked from the cache. This affected Smashing Magazine, and support for this is also being worked on.

These are among the most common reasons, but there are many more. The complete list of reasons can be found in the Chrome DevTools Protocol source, and a more detailed explanation is available in a supplementary sheet.

Testing With Chrome DevTools

Instead of auditing each potential blocker manually, Chrome has a built-in test in DevTools under the Application tab. Running it will report success or list the specific reason your page cannot be cached. Third-party scripts are a common culprit here, even if you don't use these features directly in your own code. A query on HTTP Archive data identified popular third-party scripts that still use unload listeners, though many vendors have since updated their libraries.

If you discover that a service you rely on is using an unload listener, contacting them is a reasonable step — especially if you're paying for the service. The Chrome team has also been reaching out to these companies to encourage them to remove the blocker.

Note that this test only applies to Chromium-based browsers. Safari and Firefox have their own implementations and no equivalent debugging tool, so passing in Chrome is a good baseline. Manual testing with a throttled network can offer some indication, but this is subjective and prone to false results.

Smashing Magazine’s Own Case Study

Smashing Magazine was already performing well on Core Web Vitals, consistently hitting LCP numbers under the 2.5-second threshold. After a January change to delay some JavaScript, they improved to nearly 2.2 seconds. But the site was still failing the Back/Forward Cache test because of an App Install Banner tied to its PWA setup.

Removing the key parts of manifest.json to disable the banner had a dramatic effect. LCP dropped to 1.7 seconds — the best number the site had ever recorded since beginning the Core Web Vitals initiative. The CrUX dashboard confirmed the improvement over the following months. The site had no CLS issues, so the gain showed up entirely in LCP, but other sites may see a different mix of improvements.

This is not a universal recommendation. Sites that are more app-like might legitimately value the install prompt more than the cache speed benefit. The decision requires weighing what the blocking feature gives you against the lost performance. You can also use a custom dimension in your analytics to measure how many navigations would be affected.

Run The Test Today

Running the test takes only a couple of seconds. If your page is ineligible, investigate the reason and consider whether the blocking feature is worth the cost. Check more than one page, since different templates may load different code. If the blocker comes from your own code, determine whether it's providing enough value. If it comes from a third party, raise the issue with them. If it's a browser limitation, reporting it to the Chrome team can help prioritize a fix.

Sites that are ineligible for the Back/Forward Cache are leaving free performance on the table, making Core Web Vitals more difficult to pass than necessary. The rollout in Chrome has already delivered measurable gains for eligible sites, and there is more to be had if you can remove the blockers holding you back.