Field data shows most Back navigations to your site are full page loads rather than back/forward cache restores. How do you find out, page by page, why the browser refused to restore each one?

## Why you cannot guess Eligibility is decided by the whole page — your bundle, every third-party tag, every cross-origin frame, and the document's own response headers. A page can look clean in your source and still never be restored because one vendor script registers an `unload` listener, or because a CDN rule adds `Cache-Control: no-store`. You need attribution, not intuition. ## The local tool: DevTools Chrome DevTools' **Application** panel has a **Back/forward cache** tool. Its test button drives a real navigation away from the current page and straight back, then reports one of two outcomes: the page was successfully served from the back/forward cache, or it was not — with a list of reasons. The reasons are specific enough to act on, and they are grouped by whether they are actionable in your code, browser-internal circumstances, or not supported yet. The crucial detail is that the tool performs an actual traversal. You cannot reproduce a restore by reloading, retyping the URL or clicking a link — those are new navigations. Any manual test must use Back/Forward, `history.back()`, or this tool. ## The field signal: navigation timing For real users, the browser exposes the outcome on the navigation timing entry: ```js const [nav] = performance.getEntriesByType('navigation'); if (nav.type === 'back_forward') { // this was a history traversal; it may or may not have been a restore console.log(nav.notRestoredReasons); } ``` `type === 'back_forward'` tells you the navigation was a history traversal. It does **not** tell you a restore happened — a traversal to an ineligible or evicted page is an ordinary load with that same type, which is precisely the population you are investigating. `PerformanceNavigationTiming.notRestoredReasons`, available in Chrome 123 and later, closes that gap: on a traversal that was not restored, it carries a structured report of why, with a tree that mirrors the frame hierarchy so a blocking cross-origin iframe can be attributed rather than guessed at. Feature-detect it (`'notRestoredReasons' in nav`) because it is Chromium-only, and expect the reason strings to change as browsers change behaviour — treat them as a diagnostic dimension, not a stable contract. ## The universal in-page signal On any browser, `pageshow` with `event.persisted` gives you the binary outcome: ```js window.addEventListener('pageshow', (event) => { reportMetric('bfcache_restore', event.persisted ? 1 : 0); }); ``` Combine the two and you get a usable funnel: how many navigations are traversals, what share of traversals were restores, and for the rest, the ranked reasons. ## Turning data into fixes The reasons cluster into a small number of causes with known remedies. An `unload` listener anywhere in the page — audit your own bundle and every third-party tag, then move the work to `pagehide`. `Cache-Control: no-store` on the document — check whether it was intended for this route or applied globally by a CDN rule, and narrow it. Open or in-flight connections at navigation time — close sockets and stop long-running work in `pagehide`, and restart in the `pageshow` restore branch. A blocking cross-origin frame — take it to the vendor, or load the frame lazily so it is not present at navigation time. ## Guarding the win Eligibility is a regression-prone property: it is invisible in normal QA, it is binary, and one added tag turns it off. Teams that care about it wire the check into CI — a headless run that navigates away and back and asserts a restore — and keep the field eligibility rate on the same dashboard as their other page metrics. Being able to describe that loop, rather than only naming the DevTools panel, is what separates a senior answer here.