Preload vs Preconnect: Resource Hints and When to Use Each

Choosing between preload vs preconnect starts with knowing how a browser works. It reads your HTML from top to bottom and discovers what it needs as it goes. A font named inside a stylesheet, an image set as a CSS background, or a script that loads another script are all found late, and every third-party origin costs a DNS lookup and a secure connection before the first byte arrives. Resource hints let you tell the browser about those things earlier. The risk is that each hint also competes for bandwidth and attention, so more hints is not better.

This guide explains both, plus the two related hints, dns-prefetch and prefetch, in plain language. It is for site owners and developers who can edit the <head> of a page or add an HTTP header. You will leave knowing which hint solves which problem, how to write each one correctly, how to check that it worked, and when to take it out. It makes no promise about speed: the effect depends on your page, your hosting and your visitors' networks, and you have to measure it.

Short answer: Preload fetches a specific file the current page will need but the browser finds late. Preconnect opens the connection to another origin early. DNS-prefetch only resolves the domain name. Prefetch fetches a resource for a likely next page. Use preload and preconnect sparingly, only after measuring.

Before you begin

You need to be able to edit page templates or response headers, and you need a way to see the loading order. Chrome DevTools (Network panel, with the waterfall column) is enough. Pick one or two representative pages, for example the home page and a typical article, and record the timing of your Largest Contentful Paint (LCP) element before changing anything. If you have not done that yet, see Fix Largest Contentful Paint (LCP) on Mobile. Test on a staging copy where you can, because a wrong hint can cause a file to download twice.

Preload vs preconnect: what is the difference, and where do dns-prefetch and prefetch fit?

Hint	What the browser does	Use it for	Cost if you are wrong
`rel="preload"`	Fetches and caches one specific file for the current page, at a priority based on its `as` type. Does not run scripts or apply stylesheets.	A font, hero image, critical CSS or script that is discovered late.	A wasted download that competes with resources you do need.
`rel="preconnect"`	Starts the connection to an origin early: DNS, TCP and, for HTTPS, TLS.	One or two origins you will certainly use soon.	An idle connection (browsers close unused ones after about ten seconds) and some CPU and bandwidth.
`rel="dns-prefetch"`	Resolves the domain name only.	Lower-priority third-party origins, or a fallback for preconnect.	Very small.
`rel="prefetch"`	Fetches a resource for a likely future navigation, at low priority, into the HTTP cache.	The next page or its assets.	Wasted data, and no benefit if the user goes elsewhere.

The HTML Standard's wording differs between the hints: for preload, the user agent must fetch and cache the target for the current navigation, while for preconnect, dns-prefetch and prefetch it should. In practice, treat preconnect, dns-prefetch and prefetch as hints a browser may ignore, and web.dev notes a browser may complete only part of a preconnect.

Step-by-step instructions

Step 1: Find what is discovered late

Open DevTools, reload with the cache disabled, and look at the waterfall. Two patterns point to a hint. A file that starts only after a stylesheet or script has finished (a font, a CSS background image, a lazily-injected script) is discovered late, so it is a preload candidate. A long first bar of DNS, connection and SSL time before a third-party request (analytics, a font host, a CDN, an embedded video) points to a preconnect candidate.

Lighthouse used to list these as separate audits. Chrome's documentation now says the preconnect audit has moved into the Network dependency tree insight and the preload audit has been removed as of Lighthouse 13, so look at the current report's insights. Treat any tool's savings figure as an estimate. For help with the report, see How to Read a Lighthouse Report.

What success looks like: You have a short list of at most a few files and origins that start late and that matter for what the visitor sees first.

Step 2: Preconnect to the one or two origins that matter most

Add a preconnect hint near the top of <head>, before the stylesheet or script that triggers the request:

<link rel="preconnect" href="https://cdn.example.com">
<link rel="preconnect" href="https://fonts.example.net" crossorigin>
<link rel="dns-prefetch" href="https://fonts.example.net">

Use crossorigin when the later request is made in CORS mode, which is always the case for fonts. web.dev explains that fonts load in anonymous mode, so without crossorigin the browser only performs the DNS lookup for that hint. Give dns-prefetch its own tag as a fallback for browsers that do not support preconnect; web.dev warns that putting both values in one rel makes Safari cancel the preconnect. You can also send the hint as an HTTP header, which MDN shows as Link: <https://example.com>; rel="preconnect".

Preconnect helps only for other origins: for your own origin the connection is already open. Keep the number small. web.dev says excessive preconnects consume bandwidth with TLS certificate exchanges and can delay other important resources, and Chrome's Lighthouse documentation warns that they cost CPU time, particularly for secure connections. For the rest of your third-party origins, use dns-prefetch. If scripts from those origins are the bigger problem, read Third-Party Scripts and Performance.

What success looks like: In the waterfall, the connection phase for that origin now happens early, before the request that uses it, and you can see the connection reused.

Step 3: Preload a late-discovered file, with the right attributes

A preload needs to match the real request or the browser may fetch the file twice. Always set as, set type where useful, and add crossorigin for fonts:

<link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/hero.avif" as="image" type="image/avif" fetchpriority="high">
<link rel="preload" href="/css/above-the-fold.css" as="style">

MDN lists the as values fetch, font, image, script, style and track, and says font and fetch preloads require crossorigin because fonts are always fetched in anonymous CORS mode. web.dev adds that omitting as, or using an invalid value, makes the request behave like an XHR and can lead to a script being fetched twice, and that a font preload without crossorigin is fetched twice. MDN also warns against preloading several formats of one resource, since browsers that support more than one will fetch both: preload only the format most visitors will use.

For responsive images, MDN explains that you can add imagesrcset and imagesizes to the preload so the browser picks the same candidate as the <img>; the values must match, or the wrong file may download. See Responsive Images with srcset and sizes. For fonts, pair preload with a sensible font-display: How do I load web fonts without layout shift? and Font Display Swap cover that. A preload only fetches; it does not run a script or apply a stylesheet, so the normal <script> or <link rel="stylesheet"> still has to be there.

What success looks like: The file starts downloading near the top of the waterfall, only once, and the page then uses it.

Step 4: Raise the priority of the LCP image, if the browser underrates it

fetchpriority is not a resource hint for discovery; it changes the priority of a fetch the browser already knows about. web.dev lists the values as high, low and auto (the default), and says it works on img, link and script elements and in fetch(). It describes it as a hint the browser may override. For an LCP <img> that is in the HTML, fetchpriority="high" on the image is usually enough and a preload is unnecessary, because the browser already discovers it early. A preload helps when the LCP image is a CSS background or is injected by script, and web.dev notes you can combine the two. Do not mark many resources high: the attribute only means something relative to the others.

<img src="/img/hero.avif" width="1200" height="600" alt="Workshop with finished chairs" fetchpriority="high">

web.dev lists Chrome and Edge 102, Firefox 132 and Safari 17.2 as the first versions that support it; unsupported browsers ignore it.

What success looks like: The LCP image request is among the first image requests in the waterfall, and your LCP measurement does not get worse.

Step 5: Prefetch only when you can predict the next page

rel="prefetch" is for the next navigation: the response is stored in the HTTP cache, at a lower priority than preloads, so it can speed up a very predictable next step such as the checkout page after the cart. MDN lists caveats: headers like Cache-Control: no-store can stop it, many browsers partition the cache by site, support is limited, and MDN recommends the Speculation Rules API for prefetching documents where supported. Never prefetch pages that change state, such as a logout link, or large files on metered connections.

What success looks like: The next page's assets are served from cache when the visitor arrives, and you can see a prefetch request in DevTools before they click.

Step 6: Verify, measure and prune

Reload with DevTools open and look for console warnings. web.dev notes that Chrome logs a warning for a preload that is not used within about three seconds of the load event; it usually means a mismatched URL, as or crossorigin. Compare LCP and the rest of your waterfall before and after, on throttled mobile settings and, where you have it, in real-user data (see Field Data vs Lab Data). Remove any hint that cannot show a benefit. web.dev warns that too many preloads dilute prioritisation so none of them gets priority, especially on slow networks.

What success looks like: Each remaining hint has a reason, a console with no unused-preload warnings, and a measured result.

Final verification checklist

Your preload vs preconnect choices each answer a specific late-discovered file or a slow connection seen in the waterfall.
Preconnect is used for no more than a few critical third-party origins, with crossorigin where fonts or CORS requests are involved.
dns-prefetch covers lower-priority origins and sits in its own tag.
Every preload has a correct as, matching URL and, for fonts, crossorigin.
Only one image format is preloaded, and responsive preloads match the <img>.
fetchpriority="high" is used on at most the LCP element.
No unused-preload warning appears in the console.
Before and after measurements are saved, and hints without a benefit are removed.

Common mistakes to avoid

Preloading everything. Prioritisation is relative, so a page full of preloads has none. Keep to a few high-value files.
Missing crossorigin on font preloads. The font downloads twice.
Preconnecting to your own origin. It adds nothing.
Preconnecting to ten third parties. Choose the critical one or two and use dns-prefetch for the rest.
Preloading a resource the page then does not use. Fix the URL or delete the hint.
Preloading a hero image that is lazy-loaded or hidden on mobile. The preload still downloads it; use media on the preload, as MDN shows, or drop it.
Using hints instead of fixing the cause. A very large script is better made smaller: Reduce JavaScript Bundle Size.
Leaving old hints after changing providers. Audit them whenever a font, CDN or script changes.

Frequently asked questions

Is preload or preconnect better?

Neither is better; they solve different problems. Preload fetches a known file the browser finds late. Preconnect warms up a connection to an origin you will request from soon.

Should I use both preload and dns-prefetch for the same file?

No. Dns-prefetch concerns an origin's name, not a file. It makes sense next to a preconnect as a fallback, or for origins you are less sure about.

Do resource hints improve SEO?

This guide cannot promise that. Hints may make your key resources arrive sooner, which can help metrics such as LCP, and Google's documentation on Core Web Vitals is the place to read how those metrics are used. Treat the effect as something to measure on your own pages.

Can I add hints in an HTTP header instead of HTML?

For preconnect and preload, yes: the HTML Standard's link type table lists Link header processing for both, and MDN shows the preconnect form as Link: <https://example.com>; rel="preconnect". Check your server or CDN documentation for how to add the header.

Is rel="modulepreload" the same as preload?

It is a related hint for JavaScript modules: the browser fetches the module script and stores it in the document's module map, and MDN's preload page recommends it for modules.

Official references

Next step: Try the free website sample to see how your own site does on a few of these checks. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.