A wrong prefetch wastes resources and yields nothing
Aliases: prefetch miss · wrong next-hop bet · unused speculative fetch
What it is
Prefetch is a bet. A wrong bet — the person went somewhere else, the predicted object expired, the version fetched is the wrong one — still spends bandwidth and battery, and the next hop’s wait is not shorter by a millisecond. That is a miss: the debit posts, the credit is zero. Error here is not “a bit slower”. It is this prefetch being deleted from the ledger. Keep betting with the same rule and you manufacture cost with no yield, stably.
Why it happens
A hit needs both ends to match: the object and the moment. Wrong object: the hover was a lapse, the real tap is the neighbour; a global “first item” probability is applied to someone who came to find the twentieth. Wrong moment: the content was right when fetched and wrong when tapped — stock, permission, session changed. There is also a semantic miss: prefetch consumes a draft meant to be submitted, or a one-time link, and the real operation meets “already used” or “not the copy I just saw”.
Misses hide because the UI can look unchanged — the next hop still spins, as if prefetch never ran. Cost lives in the radio and the bill, not in pixels, so a product can lose for a long time without seeing it. Worse, a miss can poison cache: a page for the wrong identity or experiment arm is stored, and the next “hit” is a quiet wrong content. The debit upgrades from waste to false presentation.
Where it stops holding
Exploratory browsing has a naturally low hit rate; demanding “next chapter in a reader” success of every card in a shop rewrites this leaf as a prefetch ban. The allowed move is to bet only where the path is truly narrow, and to accept that exploratory paths do not prefetch. Missing metadata and missing a whole page are different magnitudes: a light miss can be a learning signal (this rule does not fit this kind of user); a missed video is an incident. Explicit cancel, back, or closing the page should void the matching bet at once; do not let a now-useless transfer run to completion. When hit rate is low but a hit is huge (a cold editor), a very narrow prefetch may stay, but only if miss rate is visibly gated by budget, not kept alive on “what if”.
Applying it
- Record hit rate per prefetch rule. Turn a rule off if it stays under the threshold; do not keep it for a handful of delightful hits.
- Tag prefetch results with identity and freshness. Drop them on user change, permission change, or expiry. Never treat a missed wrong cache as the next hop’s speed.
- Cancel in-flight prefetch when the person leaves the predicted path (back, close, picked another item).
- How to check: read a week of prefetch logs. If a rule’s transfers are mostly never used in that session, and next-hop wait looks the same as with prefetch off, the rule is stably buying nothing.