You own web performance across several product teams and want back/forward cache hit rate treated as a tracked number. How would you set a target for it, and how would you decide when chasing eligibility is not worth the engineering cost?

## Why a single sitewide target is the wrong instrument A sitewide back/forward cache hit rate is an average over templates with wildly different back-navigation volumes. It moves for reasons that have nothing to do with engineering — a traffic shift, a campaign, a seasonal change in what people browse — and it hides the one distribution that matters: which templates are eligible and which are not. Eligibility is binary per page load, so the honest report is closer to a checklist per template, weighted by the share of back navigations each receives, than to a single decimal teams are asked to nudge upward. So the first move is a baseline, not a target. Measure the current restore rate per template and per device class, and measure how much back navigation each template receives at all. Only then do you know whether the opportunity deserves a quarter of anyone's attention. ## Setting targets that mean something Where back navigation is a core loop — search results, category listings, feeds, job or property boards — a hard eligibility requirement is reasonable: this template is restorable, and a check enforces it. Where back navigation is rare, no target at all is the right answer; asking a team to move a number that affects a fraction of a percent of their traffic spends credibility you will want later. Guard against the two ways the metric gets gamed or misread. First, it is a ratio, so it can improve because the denominator shrank, which is not a win. Second, a rising hit rate lifts your aggregate field vitals with no change in how fast pages load, so if teams are also judged on a vitals pass rate you must keep restores and cold loads legible as separate segments — otherwise you congratulate people for the wrong thing and, worse, miss a genuine cold-load regression hiding under a growing share of restores. ## When chasing eligibility is the wrong call Three cases where I would explicitly stop: **The blocker belongs to someone else.** A required third-party tag that makes a template ineligible is not an engineering ticket, it is a negotiation. The options are removal, a route or consent gate, a vendor upgrade, or acceptance. If the tag genuinely earns its place commercially, accepting a lower restore rate there is a legitimate decision — provided it is written down as a decision rather than left as an open bug that gets re-litigated every quarter. **The blocker is protecting something.** Configuration that prevents a document from being stored is sometimes deliberate — sensitive content, a compliance requirement, a call someone made and never documented. "Remove the header" is a fine suggestion only once you know why it was added. Reversing a security or correctness decision to buy a performance number is the classic way a performance program loses trust. **The page must not come back stale.** A restored page returns with the data it had. Prices, cart totals, live counts, permissions that may have changed in another tab — all of that needs a deliberate refresh path on restore, and that path has to be built and tested. Sometimes it is cheap; sometimes it means threading revalidation through a state layer that was never designed for it. When that exceeds the value of instant back navigation on that template, leaving the page ineligible is the correct engineering decision, not a failure. ## Make it a guard, not a campaign The defining property of this lever is that it regresses invisibly. Nothing breaks when a page becomes ineligible: no test fails, no error is logged, no user complains in a way anyone can attribute. A shared layout gains a listener, an edge config gains a header, a vendor ships a new tag version — and last quarter's gain is gone with no signal at all. So the durable investment is not the fix, it is the ratchet: a synthetic eligibility check per key template running in CI so a regression fails a build, plus an alert on the field restore rate per template so anything that slips past the synthetic check surfaces in days rather than at the next audit. That converts a one-time win into a property of the system, which is the only form in which this kind of gain survives reorganizations and team turnover. ## How I would present it upward Tied to user outcome and honest about coverage: what share of back navigations on the templates that matter are instant, what that is worth in journeys where back navigation is the core loop, which templates are deliberately excluded and why, and what stops the number falling back. Field reporting of blocking reasons is Chromium-only today, so the figure describes part of your audience and should say so. A performance program that reports a metric without its limits and its guard is reporting a snapshot, not a capability.