Chrome now ignores Cache-Control: no-store

Chrome is about to supercharge page navigation for millions of websites by ignoring a common performance-killing HTTP header. This under-the-radar change could dramatically improve your Core Web Vitals with zero developer effort by enabling bfcache for pages with Cache-Control: no-store. How do you know if you will benefit? (Spoiler: if you're using Magento, you probably won't.)

  • by Karlijn Löwik
  • Published
  • Reading time ± 4 minutes
  • Browser APIs
Chrome now ignores Cache-Control: no-store

If you've been following Chrome's latest updates or seen our recent talks, you might have seen a significant change happening right now. Chrome is changing how it handles Cache-Control: no-store headers, and this has major implications for performance across the web. The rollout is expected to complete by April 2025, so now's the perfect time to understand what this means for your sites.

What's changing with back/forward cache?

Simply put, Chrome is now enabling back/forward cache (bfcache) for pages that use Cache-Control: no-store in certain situations. Why does this matter? Because until now, using this header automatically made your pages ineligible for the back/forward cache.

For context, bfcache is what allows almost instant page navigation when users hit the back or forward buttons. Instead of reloading the entire page from scratch, Chrome keeps it in memory and just restores it. The difference is dramatic – think 100-200ms versus several seconds for a full page load.

Chrome's data shows this affects about 17% of history navigations on mobile and 7% on desktop. That's a lot of potentially improved user experiences.

Of course, Chrome isn't making this change blindly. They've implemented several safeguards:

  • They're only keeping these pages in bfcache for 3 minutes (rather than the usual 10 minutes)
  • If a user's cookies change, the page gets evicted from the cache
  • Pages using WebSocket, WebTransport, or WebRTC still can't use bfcache

Why eCommerce would really benefit from this chane

Think about the typical shopping experience – users frequently navigate back and forth between product listings and detail pages. Previously, every "back" click triggered a full reload for these Magento sites. Now, many of these navigations will be nearly instant.

If they qualify. But.. they very often might not.

Bad news if you are using Magento

If you are using Magento, it would make sense to feel very enthoustastic about this change. I sure did when I first read it! Why? Because accoring to HTTP Archive, a whopping 89% of Magento sites use Cache-Control: no-store.

Before you get too excited though: I have bad news for you. Magento uses "Set-Cookie Headers" all the time in the HTML response, making it ineligable to benefit from this change.

Meaning: you will still have to get rid of the Cache-Control: no-store code if you want to benefit from bfcache.

And even after you've done that, please also note that the same data shows that 26% of Magento origins use WebRTC and 10% use WebSocket connections – both of which will still block bfcache regardless of this change.

What this means for your Core Web Vitals and RUM data

If you're tracking Core Web Vitals (and you should be😉), this change could give your metrics a nice boost:

  • Largest Contentful Paint (LCP) virtually disappears for back navigation – the content is already there
  • Cumulative Layout Shift (CLS) is minimal since the page is restored whole, not built progressively
  • Interaction to Next Paint (INP) improve dramatically as the page is immediately interactive

Real User Monitoring data often shows that back/forward navigation makes up a significant portion of page views, so these improvements can substantially impact your overall scores.

How to test this on your sites

Want to see how this affects your specific site? Here's what to do:

  1. Launch Chrome with this flag: --enable-features=CacheControlNoStoreEnterBackForwardCache:level/restore-unless-cookie-change
  2. Open Chrome DevTools and use the Application tab's back/forward cache section to test compatibility
  3. Look at your CrUX Dashboard to monitor bfcache usage as this rolls out, or check it out in our free tool. Do remember, CrUX comes with a 28 day delay.
  4. If you already use RUMvision, this might explain how your bfcache successhits went up.

Enterprise concerns

If you're in an enterprise environment where this change might cause issues, Chrome has you covered. You can disable it via the AllowBackForwardCacheForCacheControlNoStorePageEnabled policy.

Your action plan

Here's what every developer should be doing now:

  1. Review your cache headers – Are you using Cache-Control: no-store when you don't really need to? Still remove them please.
  2. Check for WebRTC and WebSockets – These will still block bfcache regardless of the header change
  3. Replace unload with pagehide – This is just good practice anyway, especially with unload deprecation looming
  4. Update your analytics – Make sure you're tracking bfcache restores correctly
  5. Add refresh mechanisms – For time-sensitive content, implement targeted updates on restore

I've written a whole article about all you need to know about bfcache if you want more information.

Woohoo, free performance boost!

Chrome's change is essentially giving many sites a free performance boost. Pages that were previously forced to reload completely might now restore instantly from the bfcache.

The best part? For many sites, this improvement will happen automatically, without any code changes. But by following the recommendations above and fixing reasons why bfcache is still hindered, you can ensure your site gets the maximum benefit from this update while maintaining accurate analytics and fresh content.

As web performance continues to impact everything from user experience to SEO rankings, these "free" optimizations become increasingly valuable. So, thanks Chrome!

Share blog post