Articles

Resource Hints: Preload, Prefetch, and Preconnect

Resource hints like preload, prefetch, and preconnect tell the browser what to fetch early. Here's how each one works and when to reach for it.

Takina Takina · · 4 min read
Code editor showing a component's markup

Resource hints are small <link> tags that tell the browser about resources it will need before it discovers them the normal way, so it can start fetching, connecting, or parsing earlier than it otherwise would. The three most useful ones — preload, prefetch, and preconnect — solve different problems, and mixing them up can hurt performance instead of helping it.

All three work by adding a hint to the <head> of your document, and all three are advisory: the browser decides how aggressively to act on them based on bandwidth, cache state, and its own heuristics. They don’t force anything; they just move a fetch earlier in the queue.

What each hint does

  • preload tells the browser to fetch a resource the current page will definitely need soon — a font, a hero image, a critical script — at high priority, before the browser would normally discover it while parsing CSS or JS.
  • prefetch tells the browser to fetch a resource the next page will probably need, at low priority, using idle bandwidth so it doesn’t compete with the current page’s load.
  • preconnect tells the browser to open the network connection (DNS lookup, TCP handshake, TLS negotiation) to a third-party origin ahead of time, without fetching anything yet.
HintFetches the resource?PriorityUse case
preloadYesHighThis page needs it, right now
prefetchYesLow (idle)The next page will probably need it
preconnectNo — connection onlyMediumThis page will request something from that origin soon

When to use preload

preload is for resources the browser wouldn’t otherwise discover until late in the critical rendering path — most commonly a web font referenced only inside a CSS file, or a large hero image that isn’t in the initial HTML as an <img> tag (for example, one set via CSS background-image).

<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

The as attribute matters — it tells the browser what kind of resource this is so it can apply the right request priority and content-security-policy checks. Omitting it, or getting it wrong, causes some browsers to fetch the resource twice.

The failure mode to watch for is over-preloading. Every preload competes for bandwidth with everything else the page needs on first load. Preloading five things means none of them gets true priority — reserve it for the one or two resources that block the largest contentful paint, which is one of the metrics covered in our Core Web Vitals guide.

When to use prefetch

prefetch is a bet on where the user goes next. If your analytics show that most visitors on an article page click through to a specific related post, prefetching that post’s JS chunk or data means it’s likely already cached by the time they click.

<link rel="prefetch" href="/blog/next-likely-article/" as="document">

Because it runs at low priority during idle time, prefetch is safe to be generous with — a wrong guess just wastes a bit of bandwidth, it doesn’t slow down the current page. This is the same idea frameworks use when they prefetch links as they scroll into the viewport; if you’re on Astro or a similar framework with built-in link prefetching, it’s usually doing exactly this under the hood.

When to use preconnect (and dns-prefetch)

preconnect is narrower and more expensive per-use than the other two — each preconnected origin holds open a connection, and browsers cap how many they’ll do concurrently. Use it only for origins you know the current page will request from imminently: a font CDN, an analytics endpoint, an API host on a different domain than your CDN.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

dns-prefetch is the lighter-weight fallback — it only does the DNS lookup, not the full TCP/TLS handshake — and is worth adding as a safety net for older browsers that don’t support preconnect, or for origins you’re less certain you’ll need:

<link rel="dns-prefetch" href="https://fonts.gstatic.com">

Don’t preconnect to more than four or five origins. Past that point you’re just spending the connection budget on things that might not matter, at the cost of things that do.

Common mistakes

The most common mistake is treating these hints as free performance — adding preload to everything “just in case.” Each hint has a real cost in contention for bandwidth or connection slots, so hints only help when they’re targeted at the actual bottleneck. Profile first (Lighthouse or your browser’s network panel will show you what’s blocking largest contentful paint), then add the specific hint that addresses it.

The second most common mistake is preloading a resource that the browser was already about to fetch at high priority anyway — for instance, an <img> tag near the top of the HTML. In that case preload does nothing useful; the browser’s own parser-driven discovery was already fast enough.

The takeaway

preload fetches something this page needs, now, at high priority. prefetch fetches something the next page will probably need, at low priority, using spare bandwidth. preconnect skips straight to opening the connection without fetching anything. Used sparingly and aimed at a measured bottleneck, all three shave real time off perceived load; used indiscriminately, they just add contention. Measure first, then hint.

Takina Takina · · 4 min read

What Is the Beacon API? navigator.sendBeacon()

The Beacon API lets a page send one last async request as it unloads, without blocking navigation or racing the browser's page teardown.

#Web Development #Frontend #Performance
Takina Takina · · 5 min read

CSS will-change Explained: Compositing and Performance

The CSS will-change property hints the browser to prepare an element for an upcoming change, moving it to its own compositor layer. When to use it and when not to.

#CSS #Web Development #Performance