The Cartographer's Unseen Ink: On the Unmeasured Terrain of a Browser's Prefetch

We spend so much time carefully charting the resources our pages need, drawing precise lines from our HTML to our CSS, our scripts, and our images. We use `preload` directives like a master cartographer’s finest pen, inscribing exact instructions for what must be fetched, and when. But what of the browser’s own instinct to explore? What happens when it looks at our map and decides to draw a few speculative lines of its own?

This instinct is called speculative preloading, or prefetching. It’s the browser’s attempt to be helpful, to read the lay of the land and anticipate the user’s next move. When a user hovers over a link, a modern browser might quietly, urgently, begin fetching the resources for that likely-next page. It’s a gesture of goodwill, a silent bet placed on the user’s intent. The problem, for us as builders of these pages, is that this activity exists just outside the edges of our own carefully surveyed territory. We cannot see it in our own performance maps; it is ink that remains invisible to us.

This creates a curious dissonance. Our own performance budgets, our meticulous `preload` hints, are all measured and accounted for. But the browser’s speculative work—its own guess about what comes next—happens in a separate, parallel world. It consumes bandwidth. It contends for network threads. It is a real, tangible event that has a very real impact on the user’s current experience, yet it leaves no trace in our conventional performance timelines like Navigation Timing or Resource Timing. It is the cartographer’s own journey, unrecorded on the official map.

So how do we account for this unseen travel? We must first acknowledge its existence. We must understand that a user’s hover is an event that triggers real work. Then, we can begin to measure its impact indirectly. We might listen for `performance.getEntriesByType('resource')` more broadly, watching for requests we didn't explicitly initiate. We might use the Network panel in our developer tools not as a passive recorder, but as an active observer of this speculative behavior.

The goal isn’t to stop the browser from being helpful. Its intuition is often right. The goal is to become aware of the full picture, to understand that the performance of our current page is sometimes shaped by the shadow of the next. By measuring the unmeasured, we complete the map. We see not only the routes we have meticulously planned, but also the invisible paths the browser treads on our behalf, ensuring its helpful guess doesn’t quietly undermine the experience we worked so hard to build.

Notes & further reading

A few pages I came back to while writing this: