Resource Hints: preload, prefetch, preconnect

The plain-language idea

The browser's normal resource-discovery process is good but reactive: it finds a resource (an image, a font, a script) by parsing HTML and CSS as it goes, then fetches it. Resource hints let you tell the browser about something it hasn't discovered yet, or won't discover for a while, so it can act on that information early.

Four hints, each doing a genuinely different job:

• preconnect — do the connection setup (DNS lookup, TCP handshake, TLS negotiation) for a domain now, before you know the exact resource URL you'll need from it. Right for a third-party origin you know you'll hit soon, like a font CDN or an analytics endpoint.
• dns-prefetch — the cheaper, older sibling of preconnect. Only does the DNS lookup, skipping the TCP/TLS setup. Useful as a lower-cost fallback for origins you're less certain are worth a full preconnect (browsers cap how many preconnects they'll actually honor at once).
• preload — fetch one specific resource right now, because you know this page needs it soon, even though the browser's normal parser wouldn't have found it yet. The classic case: a hero image referenced only inside a CSS background-image, which the browser can't discover until it's already parsed and applied that CSS.
• prefetch — fetch a resource a likely next navigation will need, at low priority, so it's already warm in cache if the user does go there.

See it in a real thing: warming up a checkout flow

<!-- Third-party origin we know we'll need soon -->
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

<!-- Hero image only referenced via CSS background-image —
     the browser's parser can't discover this on its own -->
<link rel="preload" as="image" href="/hero-checkout.avif" />

<!-- The user is very likely to click through to /checkout/confirm next -->
<link rel="prefetch" href="/checkout/confirm" as="document" />

preconnect gets the font CDN's connection ready before the CSS that references it has even been parsed. preload forces the hero image's fetch to start immediately, instead of waiting for CSS parsing to discover it as a background image. prefetch warms the next likely page at low priority, so it doesn't compete with anything this page still needs.

What people usually miss

Watch out

• preload doesn't change priority in a vacuum — it's a request that competes with everything else. Preloading five things means five things are now racing for bandwidth at high priority; the actual LCP image can lose that race if it's not one of the five.
• prefetch is deliberately low priority, preload is not. Using preload for a likely-next-page resource (instead of prefetch) makes the browser fetch it at a priority that can starve the current page's own critical resources.
• preconnect without a following request is wasted work. Opening a connection that never gets used still costs DNS/TCP/TLS setup time and, on some networks, keeps a socket open the browser has to clean up — only preconnect to origins you're confident you'll actually request from.
• crossorigin is required on preconnect/preload for anything fetched with CORS (most fonts), even from a same-site-feeling CDN — omitting it means the browser opens a second, differently-keyed connection or fetch when the real request happens, silently defeating the hint.
• The browser already discovers most resources fine on its own. Resource hints are for the specific cases where discovery is late or the resource lives on a different origin than the one it's linked from — not a blanket "hint everything" strategy.

Why this matters in interviews

"The hero image is defined in CSS as a background-image and it's hurting LCP — what would you do?" is a real, specific question that resource hints answer directly: naming preload with the right as value, and explaining why the browser couldn't have discovered it earlier, is a much stronger answer than a vague "optimize the image."