The Miller's Settled Stone: On the Perilous Grind of an Over-Eager `preconnect`

We live by a simple creed in the world of web performance: be proactive. Foresight is the highest virtue. If you know a resource is coming, why wait? Tell the browser to get ready. This is the gospel of the `preconnect` hint, a tiny line of code that initiates an early handshake with a third-party domain before a request is even made. It’s presented as pure upside, a free performance boost for the diligent. But I’ve come to believe this advice, applied with evangelical fervor, is often a subtle trap. Like a miller who sets his grinding stones spinning at dawn, fearing a customer might arrive, we can waste precious energy on connections that never come, starving the actual work that needs to be done.

The logic seems unassailable. A `preconnect` establishes a TCP connection, performs a TLS handshake, and gets everything in a state of readiness. When the resource—a font from Google, a script from a CDN—is finally needed, the costly connection setup is already complete. The perceived delay vanishes. The performance audits light up green. We are praised for our diligence. But this focus on a single metric, on the theoretical speed of a single resource, ignores the broader, more constrained economy of the browser.

A browser’s ability to manage connections is not infinite. There are limits on the number of simultaneous connections per domain and, more crucially, a global limit on the total number of open sockets. Preconnecting to a half-dozen third-party domains on page load, just in case, is like opening every door in a vast building in anticipation of a single guest. You’ve expended effort, locked resources, and created a sprawling, inefficient footprint. You have, in essence, created connection debt. When the critical resources—your own CSS, your hero image, your essential JavaScript—need to be fetched, they must now compete for a slot in this crowded network queue you’ve artificially created.

The Cost of Premature Handshakes

The danger is most acute on a slow network or a strained device. The browser, a diligent but finite steward, must now manage these speculative connections alongside the urgent ones. The TLS handshake you so eagerly initiated for an analytics script that fires ten seconds after page load has consumed CPU cycles and a socket that could have been dedicated to rendering the content above the fold. The miller’s stone grinds nothing but air, and the sound of its spinning masks the quiet hunger of the village waiting for flour.

So, what is the alternative to this preemptive frenzy? It is a more sober, more strategic form of anticipation. Instead of a blanket `preconnect` for every external domain in sight, we must practice connection hygiene. Use `preconnect` for a single, critical, and imminent third-party resource—the primary font provider, for instance. For others, the more polite `dns-prefetch` might suffice, resolving the domain name without the heavier commitment of a full connection. Better yet, reconsider the architecture. Can the resource be hosted first-party? Can it be loaded in a less obstructive way? True performance craftsmanship isn’t about blindly applying every available hint; it’s about understanding the system’s limits and placing your bets where they truly count.

Performance is not a collection of green checkmarks; it is the felt experience of the person waiting for the page. By abandoning the cargo-cult practice of over-preconnecting, we stop grinding empty air. We allow the browser’s limited resources to be focused on the immediate task of rendering what the user came for. We let the miller’s stone settle until there is grain to grind, ensuring that when the moment for work arrives, all energy is directed, purposeful, and swift.

Notes & further reading

A few pages I came back to while writing this: