A link's payload was prefetched minutes before the user clicked it — what can go wrong, and how do you bound it?

Prefetching buys speed by doing the work early. The hidden term in that trade is **time**: the payload is an answer computed at fetch time and displayed at click time, and everything that changed in between is invisible to it. On a nav bar hovered for 300 ms this is irrelevant. On a link prefetched when it scrolled into view and clicked four minutes later, it is a correctness problem. ## The three ways a speculative payload goes wrong 1. **Stale data.** The world moved. The user created a record, completed a payment, or dismissed something, and the prefetched route still shows the state from before. It renders instantly, which makes it more convincing and more confusing than a slow but correct page. 2. **Wrong context.** The payload was computed for a state the user has left: a different identity after a session change, a different workspace or locale after a switch, a different set of permissions after a role change. Applying it shows content that the current context should not produce at all — occasionally content the current user should not see, if the payload was cached anywhere shared. 3. **A side effect that already happened.** The speculative request reaches the server as a normal request. If the target is not side-effect free, the effect occurred when the link was hovered or rendered, with no click behind it. ## Bounding the window | Bound | What it gives you | What it costs | |---|---|---| | Short hold window, then discard | staleness capped by wall-clock time | re-fetch on click if the user was slow | | Revalidate on click, show prefetched meanwhile | instant paint, converging to fresh | one request per navigation anyway | | Prefetch code only | latency win with zero staleness | the data round trip remains | | Do not prefetch this surface | always correct | full click latency | The first two are the common defaults; the third is the safest thing to do for anything personalised, because a route's code chunk does not age. The fourth is a legitimate choice: some surfaces should not be speculated on. Whether a speculative payload is discarded on a session change is the detail teams miss. Signing out, switching tenant or changing role should invalidate anything fetched before it — otherwise a prefetch made under the old context is sitting there ready to be applied under the new one. ## What to check per surface - **Volatility.** How fast does this route's answer change? Anything derived from a live figure — inventory, balances, queues, unread counts — tolerates almost no window. - **Personalisation.** Is the answer a function of who is asking? If so, warm code and leave data alone, and make sure nothing between the client and the origin caches it. - **Cost of being wrong.** Showing a stale article is a shrug. Showing a stale amount of money is an incident. - **Safety.** Is the target idempotent? If the request does anything, it must not be prefetched at all. ## Diagnosing it in the wild The symptom is a report that a page was correct after a refresh but wrong when reached by clicking, and only sometimes. It reproduces poorly because it depends on how long the link sat prefetched. Useful moves: check whether the affected navigations were served from a speculative fetch at all, look at the age of the payload at the moment it was applied, and try the same route with prefetching disabled — if the bug vanishes, the window is the cause. A timestamp carried in the payload, compared against the moment of application, turns a vague report into a measurement. ## What this is not This is about the window between a speculative fetch and the click. Once a route has actually been visited, the question of how long the client keeps that payload and what invalidates it is a separate caching concern with its own rules — prefetching just gets there first and with less certainty that the user ever wanted it. ## Where frameworks differ Some discard speculative payloads after a short fixed window, some hold them until the page unloads, some treat them exactly like a visited route's copy, and some revalidate on click as a matter of course. Because the default varies, the honest answer in an interview is to state the risk, name the bounds, and say that you would check what your framework actually does before assuming one of them.