Resource Hints: preload, preconnect, prefetch and fetchpriority
Table of contents
Your site is not always slow: often the browser discovers the important resource too late. Resource hints are directives that tell it what to connect to or download before it needs it, and they fit in a single line of HTML.
They are not a ranking factor: they are a lever on the loading metrics Google does use, and misused they make loading worse. Here is which one to use, when to avoid them and how to verify.
What are resource hints and why they affect loading
According to web.dev, resource hints instruct the browser to perform certain actions ahead of time to improve loading speed: they bring forward DNS resolution, the opening of a connection or the download of a resource. They are declared in the <head> or in an HTTP header.
| Hint | What it brings forward | Cost |
|---|---|---|
dns-prefetch | DNS resolution only | Minimal |
preconnect | DNS + TCP + TLS | Low, but real |
preload | The resource download | Bandwidth |
prefetch | A future navigation | Wasted if the user never navigates |
fetchpriority | Nothing: it changes priority | None on its own |
The problem they solve: the preload scanner only sees the initial HTML. Anything discovered through CSS (an @import, a background-image), through JavaScript or through another origin is requested late, and the later the critical resource arrives, the worse the LCP ends up.
The honest framing is the one from Google Search Central: Core Web Vitals are used by their ranking systems, but there is no single page experience signal and good metrics do not guarantee positions.
preconnect: start the connection to an origin early
preconnect negotiates DNS, TCP and TLS with another origin before the parser asks for it. It is the most expensive of the cheap hints because opening a connection consumes resources: reserve it for the two to four critical origins, such as the image CDN or the fonts.
<link rel="preconnect" href="https://fonts.googleapis.com">
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>The crossorigin caveat
Two domains: the CSS comes from fonts.googleapis.com and the files from fonts.gstatic.com. Fonts travel over CORS, so without crossorigin the browser opens another connection when downloading them and you pay the cost with none of the benefit. In Lighthouse 13, the preconnect audit lives inside the Network dependency tree insight.
dns-prefetch: the cheapest hint (and the most forgotten)
dns-prefetch only resolves the domain to an IP and does not open a connection: it fits where preconnect does not scale, on secondary origins.
<link rel="dns-prefetch" href="https://cdn.example.com">An underrated case: injecting the hint when an outbound link enters the viewport. The rule: preconnect for the critical origins and dns-prefetch for the rest of the relevant third parties.
preload: what the browser discovers late and is critical
The use case is deliberately narrow: fonts, CSS pulled in by @import, a background-image that may be the LCP image or a resource that loads JavaScript. Not for what the preload scanner already sees. It lives alongside lazy loading: critical first, offscreen later.
as is mandatory, crossorigin for fonts
as declares the resource type (style, image, font, fetch) and is not optional: without it the resource is downloaded twice. Fonts always need crossorigin, even when the file sits on your own domain.
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>LCP image and responsive preload
For the image on the first screen, the LCP optimization guide recommends this pattern:
<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">If the image is responsive, add imagesrcset and imagesizes and leave out src. Watch out for excess: preloads are downloaded at high priority, and abusing them creates contention; preload everything and your LCP goes up, not down.
fetchpriority: the highest-return lever on the LCP image
The Fetch Priority API is exposed as fetchpriority with values high, low and auto, and works on <link>, <img> and <script>.
Images are requested at low priority and only after layout, if they are within the initial viewport, does the browser raise it to high: high skips that wait. Loading happens in two phases and the first one closes when blocking scripts finish, so high pulls the resource into the first phase.
<img src="/hero.webp" width="1200" height="675" alt="Description of the main image" fetchpriority="high">Honest usage is symmetrical: high on the image you believe will be the LCP and low on the ones outside the first screen, such as carousel thumbnails. Raising the priority of many resources creates contention, and no official source publishes a fixed improvement percentage.
prefetch and Speculation Rules: preparing the next navigation
<link rel="prefetch"> fires a low-priority request for a resource used in a future navigation. It is speculative: if the user never navigates, that bandwidth is wasted. Measure it against real data and respect Save-Data.
The Speculation Rules API uses JSON rules in <script type="speculationrules"> or in the Speculation-Rules header. It targets document URLs, works on multi-page sites and replaces the obsolete rel="prerender". Its prefetch downloads only the target HTML; prerender renders it in an invisible tab, at a cost similar to an iframe.
eagerness: when to speculate
immediate acts as soon as the rules are observed, moderate waits for a 200 ms hover or a pointerdown on mobile, and conservative waits for the click. By default, list rules are immediate and document rules are conservative. Chrome caps at 50 prefetches and 10 prerenders with immediate or eager, and at 2 and 2 with a FIFO queue otherwise.
New in 2026: prerender_until_script
Chrome published in January 2026 a middle ground: prerender_until_script, in origin trial from Chrome 144. It downloads the HTML and renders with subresources, but does not execute scripts: when it hits a blocking script it pauses the parser and waits for the navigation. Use it with a prefetch fallback. The API is not Baseline, so feature-detect it with HTMLScriptElement.supports("speculationrules"); the server sees a prerender through Sec-Purpose and should initialize analytics on activation, not on render.
When NOT to use resource hints
URLs with side effects must never be prefetched or prerendered: logout, language switching, cart, logins that send an SMS code, and URLs that consume a quota, such as monthly free articles. The extreme case is URLs that fire ad conversions on the server: a speculation could report a conversion that never happened. Mitigation: read Sec-Purpose and defer whatever must not run.
Chrome caches prefetched pages for about five minutes, and robots.txt Disallow entries work as a list of suspicious URLs. If the side effect happens only in JavaScript, prefetch is safe because the script does not run until activation. The other mistakes are excess: too many high-priority preloads create contention, and speculating without real usage data burns bandwidth and CPU.
How to verify they work
In DevTools, the Network tab with its Priority column shows whether the hint appears before the resource and whether the font is downloaded twice, the usual sign of a misplaced as or crossorigin.
The Core Web Vitals report in Search Console, with thresholds of LCP under 2.5 s, INP under 200 ms and CLS under 0.1, confirms whether the improvement shows up for real users. The method: measure, apply one hint, measure again.
Checklist: the resource hints worth using today
preconnect, withcrossoriginfor fonts, to the critical origins;dns-prefetchfor the rest.preloadonly for late-discovered critical items: primary font, CSS via@importor LCP image via CSS/JS.asalways in the preload andcrossoriginon fonts; check that there is no double download.fetchpriority="high"on the LCP image (withimagesrcsetandimagesizesif it is responsive) andlowon the offscreen ones.- Multi-page navigation with a predictable flow:
prefetchand, on a light site, Speculation Rules witheagerness: moderate. - Exclude from all speculation: logout, language, cart and URLs that consume quota.
- Measure in Core Web Vitals after the change, one hint at a time.
Resource hints are the cheapest optimization in a technical SEO plan: a few lines of HTML and no new dependency. The difference between helping or hurting comes down to one thing: apply them to what is critical and measure.