Shopify Back/Forward Cache: Fix bfcache PageSpeed Warnings (2026)

Quick Fix with Thunder

What bfcache Actually Does

Back/forward cache stores a frozen snapshot of the page in memory when the shopper navigates away. If they press Back, the browser can restore the page instantly instead of rebuilding it from HTML, CSS, JavaScript, and network requests. That is a big deal for Shopify browsing behavior: product page to collection page, collection page to product page, cart back to product, and search result exploration.

Web.dev calls bfcache a browser optimization for instant back and forward navigation. Chrome's Lighthouse bfcache audit fails when the browser cannot restore the page and lists the blocking reason when possible.

This is not the same as HTTP cache or Shopify's CDN. The CDN stores files and responses. Bfcache stores the live page state. A page can have perfect static asset caching and still fail bfcache.

Why Shopify Pages Fail bfcache

The most common Shopify causes are old theme scripts, abandoned app snippets, chat widgets with open connections, analytics code that uses unload, and custom cart scripts that reset state on every navigation. Product quizzes, subscriptions, review widgets, and A/B testing tools can also introduce iframes or event listeners that make restoration unsafe.

Start by grouping blockers into two buckets: code you control in the theme, and code owned by apps. Theme code can be fixed. App code may need deferral, removal, or vendor support. Our third-party script guide helps with that app-side audit.

Step 1: Replace unload Listeners

The old pattern is to run cleanup or analytics during unload. That is bfcache-hostile. Replace it with pagehide or visibilitychange, and use navigator.sendBeacon for analytics:

// Avoid
window.addEventListener('unload', () => {
  sendAnalytics();
});

// Better
window.addEventListener('pagehide', () => {
  navigator.sendBeacon('/analytics', JSON.stringify({ event: 'pagehide' }));
});

Keep beforeunload only for real unsaved input protection. Do not use it for generic "are you sure you want to leave?" prompts on storefront pages.

Step 2: Handle pageshow Restores Correctly

Some themes break because they assume every page view is a fresh load. When bfcache restores a page, JavaScript does not restart from zero. Use the pageshow event to refresh only the state that can go stale, such as cart count, inventory badge, or logged-in UI:

window.addEventListener('pageshow', (event) => {
  if (event.persisted) {
    refreshCartCount();
    refreshRecentlyViewed();
  }
});

Do not clear the cart or reset filters just because a page was restored. Shoppers expect the page to look exactly as they left it. Refresh only data that could be wrong after time passes.

Step 3: Use notRestoredReasons to Find Blockers

Chrome exposes a NotRestoredReasons API so developers can see why a page missed bfcache. It is not a full cross-browser monitoring solution, but it is useful during debugging:

window.addEventListener('pageshow', () => {
  const nav = performance.getEntriesByType('navigation')[0];
  if (nav && 'notRestoredReasons' in nav) {
    console.log(nav.notRestoredReasons);
  }
});

Chrome's notRestoredReasons documentation explains the frame-level details. If the reason points to an iframe or app domain, audit that vendor before editing your theme.

Step 4: Audit Chat, Review, and Personalization Apps

Chat widgets often keep live connections. Review widgets and recommendation tools can load iframes. Personalization apps sometimes patch browser history or lifecycle events. None of that is automatically bad, but it can block bfcache or make restores unreliable.

Disable app embeds one at a time and rerun the Lighthouse bfcache check. Start with apps that run globally: chat, popups, analytics, A/B testing, reviews, recommendations, subscription widgets, and customer support tools. If the same app also appears in your event listener warnings or legacy JavaScript warnings, it is a stronger cleanup candidate.

Step 5: Keep Sensitive Pages Sensible

Some pages should be more conservative. Account pages, checkout-adjacent flows, and pages with sensitive personalized data may have cache-control or script behavior that limits restoration. Do not force bfcache at the expense of privacy or correctness.

Focus on high-browse pages first: homepage, collection pages, product pages, search results, and content pages. Those are where bfcache helps shoppers move around quickly and where Shopify speed improvements usually compound with conversion rate gains.

Manual Fix vs Thunder Fix

FAQ