Prefetch spends predictability to buy perceived speed
Aliases: speculative fetch · next-page prefetch · hide the wait
What it is
Prefetch fetches a resource that is likely to be wanted before anyone has said “I want this”. It does not do less work. It moves work outside the current wait so the next action hits a warm cache and perceived speed rises. The currency is predictability: the next hop has to look like a well-worn path — the first search hit, the wizard’s next step, a link hovered long enough — or the prefetch is buying a lottery ticket, not placing a bet.
Preload usually means a critical resource the current page will need shortly, started early. Both spend time to shrink a wait; what they predict differs: this page’s critical path versus the person’s next step.
Why it happens
The wait people perceive runs from intent to visible result. If the result’s bytes are already in flight or already on disk when intent is issued, that wait can fall inside the instant or continuity-of-thought window, and the action is coded as “the page was already there”. Predictability comes from stable task structure: tapping the first item in a list is far more likely than the twentieth; “next chapter” after a screen of an article is high probability; a cursor resting on a link past a threshold raises click probability. The system reads those structures as bets and spends bandwidth on them early.
When the bet hits, the slow part happens while the person is still reading the current screen or still deciding — time they were going to spend anyway — and is thus hidden in a gap that was not a wait. A missed bet turns the same hiding trick into waste, which the next two leaves take. This leaf only opens the positive ledger: without a predictable next hop there is no legitimate prefetch; with one, perceived speed comes from staggering, not from magic.
Where it stops holding
Privacy and auth can make a “looks like the next hop” resource illegal to fetch early (personalised payloads, permissions, one-time links): prefetch then retrieves the wrong identity or burns a one-shot ticket. Predictability varies by person: experts take shortcuts, novices take the first item; prefetching the global first item is systematically biased. If the current page is still fighting for bandwidth, prefetch slows what is being looked at now — speed bought on the next hop, spent on this one, net possibly negative. Prefetch must not silently complete an action that requires confirmation (pay, send). It fetches reads, not submits.
Applying it
- Prefetch only high-probability next hops: an explicit “next”, the head of a result list, a stably hovered link. Do not fire on every link on the site.
- Start prefetch after the current page’s critical path is idle, so it does not steal the pipe from what is being read.
- Treat prefetch as read-only: cache what rendering will need; do not trigger requests that change server state.
- How to check: on a typical task, compare click-to-first-frame on a prefetched path versus a cold path. The hit should be clearly shorter, and scrolling or playback on the current page should not hitch because of it, or the trade was not actually made.