Page can’t use the back/forward cache (Lighthouse)

SeverityLow

ScopeWhole site

EffortSmall

Verified byRe-crawl after you mark the task done

Rule keybfcache_blocked

Short answer

In the weekly PageSpeed Insights test, Lighthouse’s “Page prevented back/forward cache restoration” audit failed for this page. Browsers keep recently visited pages in memory so that Back and Forward show them instantly; something on this page stops that, so every return trip loads it again.

Why it matters

Back and forward navigations are a large share of all page views. With the back/forward cache they are instant; without it the visitor waits for a full load, which also counts in field data such as LCP. The causes are usually simple to remove: a Cache-Control: no-store header, an unload event listener or an open connection.

How Glimana detects it

Glimana runs PageSpeed Insights (mobile) once a week on the homepage and the most-clicked pages and stores the audits that failed. For each page, the most recent test of the last 14 days is read; the rule fires when Lighthouse’s bf-cache audit is among the failures. The evidence shows Lighthouse’s summary, such as the number of failure reasons. Pages that are not tested are not judged.

How to fix it

Find the affected pages in Glimana. Open Issues › Page can’t use the back/forward cache (Lighthouse). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
Apply the fix on your platform.

Open the page in PageSpeed Insights or Chrome DevTools (Application → Back/forward cache → Test back/forward cache) to see the exact reasons. Remove unload listeners (use pagehide instead), don’t send Cache-Control: no-store on public pages, and close WebSocket or other open connections when the page is hidden.

WordPressShopifyCustom code

Old analytics, chat and pop-up plugins often add unload listeners; update or replace them. Some cache and security plugins send no-store for every page — limit it to account, cart and checkout pages.

Most Shopify themes are compatible; the usual blockers are apps that add unload listeners or keep a connection open. Test with apps disabled one at a time to find the one responsible.

Replace unload with pagehide, send no-cache or a short max-age instead of no-store on public HTML, and close connections in a pagehide handler. Use the notRestoredReasons API to monitor the reasons in production.
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with curl -s https://your-domain/page | grep -i '<title\|canonical\|robots' that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached.
Verify in Glimana. Open the task under Tasks and click Mark as done. The weekly PageSpeed Insights test runs the audit again, and the task closes when it passes.

How the fix is verified

The weekly PageSpeed Insights test re-runs the audit; the issue closes when the bf-cache audit no longer fails for the page.