How would you measure, for real users, what share of your site's back navigations are served from the browser's back/forward cache — and what do those restores do to your Core Web Vitals field numbers?

## Define the metric before instrumenting it "Back/forward cache hit rate" only means something once you fix the denominator. The useful definition is: of all navigations that were back or forward navigations, what fraction were served by restoring the page? Two wrong denominators are common. Dividing by *all* page views produces a number that moves whenever your traffic mix changes, so a campaign full of first-time visitors makes your "hit rate" look worse with nothing changed. Counting only restores, with no denominator at all, gives an absolute number that rises with traffic and says nothing about eligibility. ## The denominator: identifying a history navigation The browser reports the navigation kind on the navigation timing entry. `performance.getEntriesByType('navigation')[0].type` returns one of `"navigate"`, `"reload"`, `"back_forward"` or `"prerender"`. A back or forward navigation reports `"back_forward"` **whether or not the page was restored** — this is the single most common misreading of the API. Seeing `"back_forward"` tells you the user pressed Back; it does not tell you they got an instant page. Treat it as the denominator only. ## The numerator: identifying an actual restore A restored page did not execute a fresh page load, so you cannot detect it with ordinary load instrumentation — code that only runs at startup never runs again. Two practical sources: - **Your RUM SDK or the `web-vitals` library.** Both already handle the restore case: a restored page is treated as a new measurement occasion and metrics are reported again. If your SDK surfaces that as a flag or a separate report, you have the numerator without writing anything. - **`notRestoredReasons`** on the Chromium navigation timing entry, which reports why a document was *not* restored. A history navigation carrying blocking reasons was rebuilt — and it tells you why, which is why the same instrumentation feeds the eligibility audit. This is Chromium-only as of 2025, so segment reporting by browser rather than presenting one blended number. ```js const [nav] = performance.getEntriesByType('navigation'); if (nav && nav.type === 'back_forward') { // History navigation: this is a denominator sample. const reasons = nav.notRestoredReasons ?? null; report('history-navigation', { rebuilt: reasons !== null }); } ``` ## Segment or the number lies A sitewide hit rate is close to useless. Back navigation is concentrated in a few journeys — search results, category listings, feeds — and those templates are usually the ones carrying the heaviest third-party payloads, which is exactly where blockers live. Segment at minimum by template and by device class. A site can show a respectable blended rate while the listing page that drives its revenue restores almost never. ## What restores do to your field vitals Because a restore is treated as a new measurement occasion, the Core Web Vitals are measured again from the restore point. In practice LCP is very small (the content is already there), layout shift is usually near zero, and the responsiveness metric — INP, which replaced FID as a Core Web Vital in March 2024 — is measured against a page whose JavaScript is already warm and whose main thread is quiet. These samples are honest: the user genuinely experienced a fast page. But they change what your aggregate means. The consequence worth stating explicitly: an improving back/forward cache hit rate raises your field pass rate *without any change in how fast your pages load*. That is a real user-experience win and worth having, but reported as one blended distribution you cannot tell it apart from "we made the page faster" — and you may miss a genuine cold-load regression hiding beneath a rising share of restores. The fix is not to discard the restores, which would understate the experience you actually deliver, but to report cold loads and restores as separate segments alongside the blended number so both effects stay legible. ## Close the loop Once the ratio exists it is both a diagnostic and a guard: paired with the blocking reasons it tells you what to fix, and tracked over time it catches the silent regression where someone adds a listener or a header and the restore rate quietly falls. Alert on the ratio per template rather than on the sitewide average, because per template is where it actually moves.