Resource hints overview

What it is

Resource hints are <link rel> declarations that tell the browser to do work earlier than the HTML parser would otherwise discover it. The W3C Resource Hints specification defines four; HTML adds two more (preload, modulepreload).

Hint	What it does	Use when
dns-prefetch	Resolve DNS for the origin.	Cheap fallback for older browsers; large numbers of secondary origins.
preconnect	DNS + TCP + TLS handshake to the origin.	You will definitely request from this origin in the next ~10 seconds.
preload	Fetch a specific resource at high priority.	Late-discovered critical resource (LCP image, font referenced from CSS).
modulepreload	Fetch and parse an ES module, including its dependency graph.	Critical JS module that would otherwise be discovered after the parser hits <script type="module">.
prefetch	Fetch a resource at low priority for a future navigation.	The user’s next likely page (article → comments, search → first result).

Why it matters

The browser’s parser discovers resources in source order. Anything referenced from CSS, JavaScript, or a late <link> is found late, after several round-trips. Hints move discovery to the start of the document so work overlaps with the rest of HTML parsing.

Used wrongly, hints harm performance — preloading 20 things slows the LCP element because everything fights for the same bandwidth. Treat each hint as a deliberate decision.

How to implement

A practical decision flow:

1. Is this for the current page?

   • Yes → next question.
   • No, it’s the next navigation → prefetch (as document for HTML, otherwise blank).

2. Is it a specific URL the browser would otherwise discover late?

   • Yes, and it’s an ES module → modulepreload.
   • Yes, anything else → preload with the correct as= (image, font, style, script, fetch).
   • No, you don’t know the URL yet but you know the origin → next question.

3. How many requests will you make to that origin?

   • 1+ — use preconnect (with crossorigin if the requests use CORS).
   • 0–1 maybe — use dns-prefetch only. Cheaper.

Example head with each hint serving a distinct purpose:

<!-- We'll request the hero from the CDN -->
<link rel="preconnect" href="https://cdn.example.com" crossorigin>

<!-- Analytics may or may not fire on this page -->
<link rel="dns-prefetch" href="https://stats.example.com">

<!-- Font is referenced from CSS, would be discovered late -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

<!-- LCP image, eager loading + high priority -->
<link rel="preload" href="/hero.avif" as="image" fetchpriority="high">

<!-- Critical module imported by /app.mjs -->
<link rel="modulepreload" href="/router.mjs">

<!-- After the user reads this article they often hit the next one -->
<link rel="prefetch" href="/articles/next" as="document">

See preload-prefetch-preconnect for syntax details and gotchas.

Common mistakes

• Preloading the same resource that is already referenced by a <link rel="stylesheet"> higher in the head. The preload scanner finds it; the hint is noise.
• Mixing preload and prefetch semantics. preload is for the current page; prefetch is for the next one.
• Forgetting crossorigin on font preloads or preconnects to CORS origins.
• modulepreload on a non-module script. Use preload as="script" for classic scripts.
• More than ~5 hints in the head. Each one competes for bandwidth.

Verification

• DevTools → Network → check the start time and priority of hinted resources. Hints should pull them left.
• Chrome console logs unused preloads after a few seconds.
• Lighthouse “Preload key requests” and “Preconnect to required origins” cover the common cases.

Related topics

• Preload, prefetch, preconnect
• Web font loading
• Critical CSS and render-blocking resources

Sources & further reading

• W3C — Resource Hints — W3C
• MDN — <link>: The External Resource Link element — MDN
• web.dev — Preload critical assets — web.dev
• MDN — rel=modulepreload — MDN