The Weaver's First Unbleached Loom: On the Unseen Friction of a Perfectly Prefetched Resource
We are taught to be anticipatory. To see the user’s next move before they make it. In the pursuit of a frictionless experience, we are handed tools like `rel=prefetch` and told to use them liberally. The logic is seductive: if a user is likely to click a link, why not gently, quietly, begin fetching that page in the background? It feels like a pure win, a silent butler smoothing the path ahead. But this practice, this eager anticipation, is not the cost-free performance enhancer we’ve been sold. It is a subtle tax on the present moment, a quiet diversion of resources from the page the user is actively trying to use.
The common advice is to prefetch the ‘most likely’ next page. But ‘most likely’ is a guess, a probabilistic gamble. Every time we make that guess, we are instructing the browser to spend a slice of its finite network and processing bandwidth on a future that may never arrive. On a struggling mobile device, fighting for a weak signal, that prefetch command is not a helpful nudge; it’s a competing demand. It can contend with the rendering of the current page, delaying the completion of a layout or the loading of an image the user is actually looking at right now. We are so focused on eliminating the potential friction of the next click that we risk adding real, tangible friction to the current scroll.
The Illusion of the Empty Pipe
This strategy is built on the flawed assumption that the network pipe is often idle, just waiting for our clever command to fill it. Modern browsers are already profoundly sophisticated in their resource management. They are not idle. They are busy prioritizing, scheduling, and managing TCP connections. Our well-intentioned prefetch can disrupt this delicate internal choreography, forcing the browser to re-prioritize our prediction over its own optimized schedule for what the user is actively doing.
Worse still is the ethical weight of this guess. We are deciding, on behalf of the user, that they should expend their data cap—their battery life, their bandwidth—on a page they haven’t asked for. In a world increasingly conscious of data sovereignty and accessibility, this presumptuous consumption feels like an overstep. It is performance optimization that prioritizes a metric over the user’s actual resources and intent.
This isn’t an argument to abandon prefetch entirely. It is an argument for profound restraint. It is a tool for the rarest of certainties, not the commonest of probabilities. The true craft lies not in predicting the user’s path, but in perfecting the ground upon which they currently stand. A genuinely fast, responsive, and stable current page is a better experience than one that stutters slightly while whispering promises about the next one. Sometimes, the most performant thing we can load is nothing at all. We must learn to trust the user’s click, and focus our efforts on making the immediate experience so solid that the transition to the next page, when it is explicitly requested, feels instant precisely because the present was never compromised.
Notes & further reading
A few pages I came back to while writing this: