How would you set a default prefetching policy across a large product's surfaces, and validate that it was right?

Prefetching is usually discussed as a per-link switch. Across a large product it is really a **budget** — the product is spending its users' bandwidth and its own origin capacity to buy navigation latency — and budgets need an owner, defaults, limits, and a way to tell whether the spend is working. ## Start by classifying surfaces, not by picking a global default A default that is obviously right for a five-item navigation bar is obviously wrong for an infinite feed, because the cost scales with the number of rendered links while the benefit does not. | Surface class | Sensible default | Why | |---|---|---| | Primary navigation, few links | early trigger, code and data | small fixed cost, very high hit rate | | Wizard or flow with a known next step | eager on the next step only | one link, near-certain | | Detail page with sibling links | intent trigger | moderate count, real intent signal | | Long list or feed | intent only, or code only | request count scales with the list | | Personalised or expensive routes | code only | data is per-user, uncacheable, ages | | Anything with side effects | never | a speculative fetch performs the action | | Slow or metered connections | off | the user is paying directly for the guess | ## Put numbers on the spend Four numbers make the policy arguable rather than aesthetic: 1. **Added requests per page view** — how many speculative fetches a typical render of this surface generates. This is the one that surprises people on lists. 2. **Added bytes per session** — total speculative transfer, and the share of it discarded. 3. **Origin capacity consumed at peak** — speculative traffic multiplies with real traffic, so it lands hardest during a spike. Prefetches a CDN absorbs are cheap; prefetches that reach dynamic route handlers are not. 4. **Wasted-fetch ratio** — prefetched and never navigated to, over all prefetches. It is the honest measure of how good the guess is. ## Validate with paired measurements A speed number alone will always look good, because prefetching does make warm navigations faster. Pair it: - Navigation latency percentiles, split by whether the payload was already in hand. If warm and cold navigations are close, the prefetch is buying little. - The wasted-fetch ratio for the same surface over the same window. - Origin request rate and error rate attributable to speculative traffic. - A field view rather than a lab one: on a fast office connection almost nothing looks expensive. Roll it out in stages — one surface, then a percentage of traffic — and hold the origin metrics next to the latency ones. Be ready to revert a surface rather than the whole policy. ## Guardrails that keep it from becoming an incident - A concurrency cap and a low-priority schedule, so speculation cannot delay what the user is looking at. - Cancellation when a link scrolls away or the user navigates elsewhere. - A kill switch that can disable speculation product-wide without a deploy, because the failure mode is amplified load at peak. - A hard rule that side-effecting targets are never speculatively fetched, enforced in review rather than by convention. - Discarding speculative state on a context change such as sign-out or workspace switch. ## The organisational part The technical policy fails if every team re-decides it per link. What works is one owned default per surface class, expressed in whatever shared link component the product has, plus an explicit escape hatch that is easy to use and visible in review. Escape hatches used routinely are a signal the default is wrong for that surface, not that engineers are careless. And the policy should be revisited when a surface changes shape: a page that grew from twelve links to two hundred has silently changed its bill without anyone editing the prefetch setting. ## What a strong answer admits That this is a judgment call with no universally correct answer; that the right default depends on the audience's connections as much as on the architecture; that the benefit is bounded by how much of the click latency is actually network; and that a route which is slow because of server work will still feel slow when it is warm only if the speculation had enough lead time. Saying prefetch everything is a signal that the candidate has never watched their own origin absorb it.