Resource hints: preload, preconnect, prefetch and more

Why hints exist

Browsers find the files a page needs by reading it. A browser does this quickly, and it even has a helper, called the preload scanner, that looks ahead in the HTML for images, scripts and stylesheets while the main parser is busy. But some files are not visible to that scan: a font named inside a stylesheet, a background image set in CSS, a script that another script loads. These are discovered late, and every moment of delay is paid for in LCP and other numbers.

A hint lets you say what the browser cannot work out in time: "you will need this font", "you will talk to this server", "you will probably want this page next". Used on the right thing, it moves a download earlier. Used on the wrong things, it wastes the network.

The hints at a glance

preload

<link rel="preload" href="/fonts/brand-latin.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/hero-1600.avif" as="image" type="image/avif">

as tells the browser what kind of file it is so that it can set the right priority and apply the right rules. For fonts, crossorigin is required, even on your own domain, because fonts are always fetched with CORS and a preload without it does not match the real request. MDN's advice for images with several formats is to preload only the type most of your visitors will use, since preloading two formats makes browsers that know both download both. For responsive images, the link takes imagesrcset and imagesizes, which match srcset and sizes.

Preload what the page needs early and the browser would otherwise find late: the font for the main heading, the LCP image set in CSS or added by a script, a critical script that another script requests. See web fonts and speed and how to fix a slow LCP. Do not preload what the browser already finds in the HTML: it adds nothing.

modulepreload

JavaScript modules load dependencies as they are processed: one module reveals the next, which reveals the next, which creates a chain. modulepreload fetches a module, parses and compiles it and keeps it ready, so that the chain can load in parallel. MDN notes that you cannot preload everything: what you choose has to be balanced against other work that it may starve.

<link rel="modulepreload" href="/js/app.mjs">

preconnect

Before a browser can ask a server for anything, it needs a connection (see connection setup): a DNS lookup, a TCP connection and, for HTTPS, a TLS handshake. For another origin, such as a font host, an image CDN or an analytics domain, that costs several round trips. preconnect starts it early:

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

It has no benefit for your own origin, where the connection is already open. MDN says that preconnecting to many third-party domains can be counterproductive, and that the hint is best used for only the most critical connections. Use crossorigin when the files will be fetched in CORS mode, such as fonts. You can also send it as an HTTP header: Link: <https://example.com>; rel="preconnect".

dns-prefetch

dns-prefetch does only the first step of a connection. It is a cheaper hint for origins that matter less, and MDN suggests it for the origins beyond the most critical few. Some sites add both for the same origin, as a fallback for older browsers.

<link rel="dns-prefetch" href="https://stats.example.com">

prefetch

prefetch is a hint for the next page, not this one. The browser fetches the file at low priority when it has spare bandwidth, and keeps it in its HTTP cache. It suits subresources of a page that the visitor is likely to open next. Headers matter: a Cache-Control of no-cache or no-store can stop a prefetch from being reused. For whole pages, MDN advises the Speculation Rules API where it is available, because it can also prerender the next page. See speculation rules.

<link rel="prefetch" href="/js/checkout.js">

fetchpriority

fetchpriority is an attribute, not a hint to start a download earlier. It says how important a request is compared with others: high, low or auto. It applies to images, scripts and link elements. Use high on the LCP image (one image, or two at most) and low on images that are above the fold but unimportant, such as slides in a carousel that are not showing.

<img src="/img/hero-1200.avif" width="1200" height="600" fetchpriority="high" alt="The shop front">

MDN says it should be used sparingly: excessive or incorrect prioritization can make a page slower, and the effect is browser dependent. It works in Chrome 102 and later, Firefox 132 and later and Safari 17.2 and later. In the 2025 Web Almanac, fetchpriority="high" was on the LCP image of 17% of mobile pages, up from 15% a year earlier, while preload was used on about 2%.

103 Early Hints

If your server needs time to build the page, the connection sits idle during that wait. With 103 Early Hints, the server can send a first, quick response that lists preload and preconnect hints while it prepares the real one, so the browser starts fetching critical files in the meantime. It works in Chrome from version 103, Safari from 17 and Firefox from 120, with differences in which hints each uses: the Chrome documentation notes that only Chrome supported preload in early hints at the time it was written.

The Chrome team's guidance is that Early Hints are not useful when your server can send the final response right away. In that case, put the hints in the page or in a Link header. Pick the hints for your top landing pages, and favor stable files: a hint for a file name that changes with every release can point to something that is no longer used. Early Hints are set at the server or the CDN, so check your platform.

Rules that keep hints useful

1. Hint only what the browser cannot find in time. Fonts, CSS backgrounds, late-discovered scripts and key origins. Not the images and scripts that are already in the HTML.
2. Keep the number small. One or two preloads, one or two preconnects, one or two high-priority images.
3. Use the right `as`, `type` and `crossorigin`. A wrong value makes the preload useless or downloads the file twice.
4. Match the real request. A preload for one file name and a page that asks for another downloads both.
5. Remove hints when the page changes. A hint for a deleted font is a wasted request.
6. Test the effect. Compare the waterfall before and after. A hint that does not move the LCP part you aimed at should go.

A sensible head

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <link rel="preconnect" href="https://cdn.example.com">
  <link rel="preload" href="/fonts/brand-latin.woff2" as="font" type="font/woff2" crossorigin>
  <style>/* critical CSS */</style>
  <link rel="stylesheet" href="/css/site.css">
  <script src="/js/app.js" defer></script>
</head>

The connection and the font come first because they take the longest to start. Critical CSS inline, the rest of the CSS and a deferred script follow. Compare with render-blocking resources and script loading.

Check your own page

Run the free audit and look at the network chain for your main image and fonts. If a font or the main image is discovered only after the stylesheet loads, a preload may move it earlier. If a third-party origin is the first thing on the critical path, preconnect to it. Then run the audit again and compare.

Sources

• rel="preload", preconnect, prefetch, dns-prefetch and modulepreload on MDN.
• fetchpriority on MDN: how it works and the warning against overuse.
• Early Hints in the Chrome documentation: when they help and how to choose hints.
• Performance chapter of the 2025 Web Almanac: adoption of fetchpriority and preload.