What is bfcache and why should you care?
Picture this: when a user clicks away from your page, instead of destroying it completely, the browser puts it in a "frozen" state—like pressing pause on a video. When the user hits the back button, rather than downloading and processing everything again, the browser simply "unpauses" the page. That's bfcache in action.
This isn't some experimental feature—it's standard in Chrome, Firefox, and Safari. It turns those frustrating back-button reloads into instant experiences. No network requests, no rendering, no layout calculations. Just instant page display.
Think about typical ecommerce browsing: a customer views product listings, clicks a product, decides it's not right, and hits back. Without bfcache, that triggers a full reload. With bfcache, it's instant.
The numbers don't lie
RUM data shows about 1 in 5 mobile navigations and 1 in 10 desktop navigations are back/forward actions. With bfcache, these can be up to 10x faster. For an ecommerce site with millions of pageviews, that's hundreds of thousands of dramatically improved experiences every month.
In fact, you can easily check it quickly yourself. Just go to RUMvisions free 6 month history tool > enter your domain -> press navigation types and you get to see both the successfull and failed bfcaches. This eCommerce site has a 28,3% navigations that are back forward, and 0% bfcache! A huge win is to be gained here!
Why it matters for ecommerce
Ecommerce sites have navigation patterns that make bfcache especially valuable:
- Category browsing between listings and products
- Comparison shopping with frequent back/forward navigation
- Cart management
- Mobile optimization (where bfcache has the biggest impact)
Yes, it matters for SPAs too (less so though)
While bfcache doesn't help with in-app soft-navigations, it's still valuable when:
- Users navigate away from your SPA and return later
- Users visit external pages and come back
- Users navigate between routes using browser history
Instead of re-bootstrapping your entire React/Vue/Angular app, the browser restores the initialized state from memory. Still: for obvious reasons MPA's do benefit more from this feature.
When browsers won't use bfcache
Browsers may not use bfcache for several reasons:
- Security & privacy concerns: Pages with sensitive financial or personal information
- HTTP headers: Pages where `Cache-Control: no-store` is set (though Chrome is ignoring this header sometimes when you set it)
- Open connections: Pages with active IndexedDB transactions, open WebSockets, or in-progress fetch/XHR requests
- Window references: Pages with a non-null window.opener reference (though using rel="
noopener" prevents this) - Browser resource management: Pages may be purged from bfcache to conserve memory, especially on memory-constrained devices
Even if you avoid all these blockers, bfcache usage isn't guaranteed - browsers make their own decisions about when to use it based on factors like available memory and user browsing patterns.
This is why measuring your site's actual bfcache hit rate is important to understand the real-world impact.
Common bfcache blockers
The main culprits that prevent bfcache from working:
- The unload event: The #1 reason sites block bfcache. Chrome is actually deprecating this event entirely.
- Open connections: Unclosed IndexedDB, WebSockets, or fetch requests
- Problematic iframes and third-party scripts
How to check if your site is bfcache-ready
- Open Chrome DevTools
- Go to Application → Back-forward Cache
- Click "Run Test"
For ongoing monitoring, track your bfcache hit rate with your RUM solution.
Making your site bfcache-friendly
- Replace unload with pagehide event listeners
- Use "
Permissions-Policy: unload=()"to prevent unload handlers - Close connections before navigation
- Update dynamic content after bfcache restore
- Review third-party scripts
Impact on analytics and measurement
When bfcache works correctly, many page loads become instant restores. Since these would have been repeat visits (which are usually faster), your average page load times might look worse even though user experience has improved.
Make sure your analytics tracks pageviews from bfcache restoration events.
What about dynamic content?
Worried about outdated prices or stock levels? When a page is restored from bfcache, you can refresh just the dynamic parts without reloading the entire page. Same for authentication - check user login status on restore and reload if necessary.
Stop leaving easy performance wins on the table
Performance optimization is complicated, but fixing bfcache blockers is the rare case where a small code change can have massive impact. Run the DevTools test on your site right now - if it fails, you've found your next high-impact performance project 😃!
