Preload and Preconnect: Shaving the Wait Off Your Page's Key Resources
A browser cannot fetch a resource it does not know about yet, and on many pages the most important resources are discovered late: a font referenced inside a stylesheet, a hero image set by CSS, or a script loaded by another script. Resource hints are small instructions in the page head that tell the browser about a resource early, so it can start work sooner. The Preload and Preconnect Builder builds the link tags for these hints, and using them well means knowing which hint fits which situation, because each hint does a different job and each has a cost.
Preconnect is the earliest and cheapest hint. It tells the browser to set up a connection to another origin, doing the DNS lookup, the TCP handshake and the TLS negotiation in advance, so that when a resource from that origin is actually needed, the connection is already warm. Preconnect is ideal for third-party origins that serve critical resources, such as a font provider or a content delivery network, because the connection setup often takes longer than the resource fetch itself. The cost is small but real: each preconnect opens a connection that consumes browser resources, so preconnecting to many origins, or to origins the page never uses, wastes effort. Two or three well-chosen preconnects are good practice; ten are not.
Preload is stronger and more specific. It tells the browser to fetch a particular resource right now, at high priority, because the page will need it shortly. Preload suits resources the browser would otherwise discover late but that are essential to the first render: the hero image, the main web font, or a critical stylesheet. The catch is that preload fetches the resource whether or not the page ends up using it, so preloading something unnecessary wastes bandwidth, and on a mobile connection that waste is felt. Preload also needs the correct as attribute, such as as="font" or as="image", and fonts additionally need crossorigin, or the browser fetches the font twice: once for the preload, once for the actual use, which is worse than no preload at all. That double-fetch trap is the single most common preload bug.
Prefetch and prerender are different tools for a different moment. Prefetch tells the browser to fetch a resource the user is likely to need on a later navigation, at low priority, so it is ready when they click. It suits the next page in a flow, not the current page. Prerender goes further and renders a whole page in the background, which can make navigation feel instant but costs far more, and should be reserved for navigations that are very likely. Confusing prefetch with preload is a common error: prefetching a current-page resource gives it low priority and may delay it, while preloading a next-page resource steals bandwidth from the current page. The names sound alike, but the timing they express is opposite.
A worked example you can follow
Take a page whose hero image is set as a CSS background and whose text uses a web font from a third-party provider. Without hints, the browser discovers the font only after downloading and parsing the stylesheet, and discovers the hero image only after applying the CSS, so both start late. Measured timings might be: connection setup to the font origin 0.35 seconds, stylesheet download and parse 0.25 seconds, font fetch 0.4 seconds, and hero image fetch 0.8 seconds, with the image starting after the CSS, so the hero appears at roughly 0.25 + 0.8 = 1.05 seconds after the stylesheet arrives, and the font at 0.25 + 0.35 + 0.4 = 1.0 second.
Add two hints: a preconnect to the font origin and a preload for the hero image. The preconnect runs in parallel with the stylesheet download, so the 0.35 second connection setup overlaps the 0.25 second stylesheet time and finishes only 0.35 − 0.25 = 0.10 seconds after the stylesheet, saving 0.25 seconds of serial waiting. The preload starts the hero image immediately, so its 0.8 second fetch overlaps the stylesheet work instead of following it, saving roughly the 0.25 seconds of stylesheet time again. The new hero timing is about 0.8 seconds from the start rather than 1.05 seconds after the stylesheet, a saving of roughly 0.25 to 0.5 seconds depending on overlap, which is a visible improvement for a two-line change. The arithmetic is approximate because real networks overlap imperfectly, but the direction is reliable: parallel work beats serial work.
Build the tags with the builder and check three things before deploying: the preconnect points at an origin the page actually uses, the preload has the right as value, and any font preload carries crossorigin. Then verify in the browser's network panel that the preloaded resource is fetched once, not twice, and that it is fetched early, not after the stylesheet. A preload that appears twice in the network log is a misconfiguration to fix, not a performance win to celebrate.
Common mistakes to avoid
The most common mistake is preloading a font without crossorigin, causing the double fetch described above. A second mistake is preloading resources the page does not use on first render, such as below-the-fold images, which steals bandwidth from what matters. A third mistake is preconnecting to every third-party origin on the page, including analytics and advertising domains that are not needed for rendering. A fourth mistake is using prefetch for a current-page resource, giving it low priority and delaying it. A fifth mistake is adding hints and never verifying them: hints are easy to mistype, and a hint pointing at a wrong URL silently does nothing while looking like an optimisation.
Resource hints are among the cheapest performance wins available, because they are a few lines in the head of the page and they exploit work the browser would do anyway, just earlier. Used sparingly and verified in the network panel, they can cut a noticeable slice off the time to first render.
Frequently asked questions
How many preconnects should a page have? Two or three for origins that serve render-critical resources; more than that wastes connection resources.
Why is my preloaded font fetched twice? Almost always a missing crossorigin attribute on the preload tag, which makes the browser treat the preload and the real request as different fetches.
Should I preload my hero image if it is an ordinary img tag? Usually not: the browser discovers an img tag early on its own, and preloading it adds little. Preload helps most for resources discovered late, such as CSS background images and fonts.
For the wider loading picture, see Website SEO Audit Guide, and pair this builder with the LCP Element Analyzer and the Resource Waterfall Analyzer when deciding what deserves a hint. Hint early, hint sparingly, and verify in the network panel.