Resource Hints

TL;DR — Resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. tell the browser to start some network work early — before it would normally figure out it needs to. There are four: dns-prefetch (look up a domain’s address early), preconnect (open a connection early), preload (fetch something the current page needs now, like your big hero image), and prefetch (quietly grab something the next page will probably need). Used sparingly they speed up your page. Used everywhere they slow it down.

What resource hints are

When a browser loads your page, it discovers what it needs as it goes. It reads the HTML, finds a CSS file, downloads it, parses it, and only then realizes there’s a font or a background image it has to fetch. That “only then” is wasted time.

Resource hints let you skip the waiting. They’re little instructions you put in the page (or in the server’s response) that say: start this now, don’t wait to discover it. Four of them do most of the work:

• dns-prefetch — “look up this domain’s address ahead of time.” Cheapest, smallest head start.
• preconnect — “actually open the connection to this domain ahead of time” (address lookup plus the secure handshake). Bigger head start, more work for the browser, so use it only for the connections that really matter.
• preload — “fetch this specific file now because the current page definitely needs it.” Best for things like your main image or a font.
• prefetch — “quietly grab this in the background because the user will probably go to that page next.”

The golden rule: don’t overdo it

The most common mistake is treating hints like a magic “make it faster” button and adding a bunch of them. It backfires. If you tell the browser everything is urgent, then nothing is — they all fight for the same bandwidth and your page can end up slower than before. A short, targeted list of hints beats a long one every time.

Do these help my Google rankings?

Not directly, and it’s worth being clear about this. Google’s crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. doesn’t benefit from your resource hints — it fetches pages differently than a real browser does. What resource hints do is make the page faster for actual visitors, and that feeds into Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., which Google’s ranking systems use as one signal among several — Google is explicit that there’s no single page-experience signal, and good Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. scores don’t guarantee a top ranking. So the chain is: hints → faster experience → better Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. → one input among many into ranking. Not “Google reads this tag and ranks you higher.”

Want the syntax, the as and crossorigin gotchas, the comparison table, and the full Core Web Vitals mapping? Switch to the Advanced tab.

TL;DR — The main resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. form a spectrum of browser cost: dns-prefetch (DNS lookup only) → preconnect (DNS + TCP + TLS) → preload (a mandatory fetch of a specific, late-discovered resource) → prefetch (lowest-priority speculative fetch for a future navigation). modulepreload is preload’s sibling for JS modules. preload is the only one the browser is obligated to fetch — that’s different from saying it’s automatically high priority; default priority still depends on the resource type, and fetchpriority is a separate hint for raising it. The as attribute is required on preload; crossorigin is required for fonts and other anonymous-mode fetches, or the browser downloads the resource twice. Overuse is the dominant failure mode. And per Gary Illyes (Feb 2026), none of this helps GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. — the SEO value is entirely indirect, through Core Web Vitals, which is one of several ranking signals, not a deterministic one.

A spectrum of browser “cost”

The cleanest mental model for resource hints is to line them up by how much work you’re asking the browser to do up front:

1. dns-prefetch — resolve a hostname to an IP. Cheapest.
2. preconnect — DNS lookup plus the TCP handshake plus TLS negotiation for HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.'. A full open connection, ready to use.
3. preload — go actually fetch a specific resource, now. The browser must process the fetch, but that doesn’t automatically make it high priority — more on that below.
4. modulepreload — preload’s sibling for JavaScript modules; fetches the module into the browser’s module map using module-script rules rather than a generic fetch.
5. prefetch — go fetch a specific resource, but at the lowest priority, for a page the user hasn’t navigated to yet.

They go in one of two places: a <link> element in the <head>, or an HTTP Link response header (more on the header path, and 103 Early Hints, below). None of this is the document-level Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. — that’s a separate mechanism for prerenderingTurning HTML, CSS, and JavaScript into the final visual page and DOM./prefetching whole navigations, covered in the prefetch section below.

dns-prefetch

dns-prefetch performs just the DNS lookup for a cross-origin server ahead of time — it doesn’t open a connection. That makes it the cheapest hint and a sensible default for the many lower-priority third-party domains a page touches (analytics, tag managers, minor widgets). In my own Largest Contentful Paint guide I make the practical point that “DNS-prefetch has better support than preconnect” — so it’s also a reasonable fallback for browsers where preconnect isn’t honored.

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

preconnect

preconnect goes further: it opens the whole connection — DNS, TCP, and (for HTTPSHTTPS is the encrypted version of HTTP — it uses TLS to authenticate the server and protect data in transit between a browser and a website. Google announced it as a lightweight ranking signal in 2014 and today conditionally prefers HTTPS pages as canonical; Chrome marks plain HTTP pages 'Not Secure.') the TLS handshake — so that by the time the browser needs the resource, the pipe is already warm. That’s a bigger win than dns-prefetch, but it’s also more expensive to the browser, which is why it comes with two important caveats:

• Reserve it for your most critical cross-origin connections. A handful (your font host, your image CDN, a critical script origin) — not everything. Google’s LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. “Preconnect to required origins” audit and web.dev both warn that unnecessary preconnects delay other important work.
• An unused connection is wasted work. Browsers close a connection that isn’t used within about 10 seconds, so a preconnect to something you don’t actually fetch soon just burns handshake capacity for nothing.

For fonts, preconnect needs the crossorigin attribute — fonts are always fetched in anonymous (CORS) mode, and without it the browser opens a second connection anyway, defeating the point.

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

preload

preload is the one the browser is obligated to execute — if it processes the tag, it must start the fetch for a resource the current page definitely needs but would otherwise discover late. That’s a statement about when the fetch starts, not automatically about priority: the default priority a preloaded resource gets still depends on the resource type and the browser (web.dev is explicit that images, for example, stay low priority by default even when preloaded). If you want to actually raise a resource’s priority, that’s a separate, explicit hint — fetchpriority — not something preload does on its own. The classic candidates for preload:

• Fonts referenced inside a CSS file — the browser doesn’t know the font exists until it downloads and parses the CSS, so preload surfaces it earlier.
• The LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (hero) image, especially one set via CSS or srcset that isn’t a plain early <img> in the HTML.
• Critical, late-discovered JavaScript or CSS.

Two attributes make or break it:

• as is required. It tells the browser what type of resource this is so it can assign the right priority and match the cache entry. Omit it and the browser treats the request like a generic XHR — wrong priority, and often a duplicate download.
• crossorigin for fonts — same rule as preconnect; miss it and the font downloads twice.

More generally, a preload only gets reused if the eventual request matches it: same URL, same as/destination, the same type or media condition, matching crossorigin/credentials mode, and — where they apply — matching integrity and referrerpolicy. For a responsive image preload, that also means using imagesrcset/imagesizes that mirror the srcset/sizes the browser would actually pick, not a single unconditional fallback URL. Get any of these out of sync and the browser either can’t reuse the preload (duplicate fetch) or fetches the wrong candidate.

For the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image specifically, Google’s current recommendation is to pair preload with fetchpriority="high" so the fetch starts alongside the stylesheet. This is the combo I describe in my LCP guide too — fetchpriority="high" gets the image earliest, and preloading is a strong second signal, useful because as I note there, “Early Hints don’t work on all browsers, so you may also want to preload the image.”

<!-- LCP image -->
<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">

<!-- Font in CSS -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter.woff2" crossorigin>

The overuse warning applies hardest here: if everything is preloaded at high priority, effectively nothing is. web.dev is explicit that excessive preloads cause bandwidth contention, and it hits hardest on slow networks. Preload the two or three genuinely late-discovered, genuinely critical resources — no more.

modulepreload

modulepreload is preload’s counterpart for JavaScript modules. Instead of a generic resource fetch, it uses module-script fetch rules and puts the result straight into the browser’s module map — so when the module is later imported, the browser already has it. Depending on the browser, it may also go ahead and fetch the module’s static imports. Support and how deep that dependency-fetching goes both vary by browser, so test the actual behavior rather than assuming it matches preload.

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

prefetch

prefetch is the odd one out: it’s not about the current page at all. It’s a low-priority, speculative fetch for a resource a future navigation will likely need — the next step in a checkout, the article a user is about to click. Because it runs at the lowest priority, it doesn’t steal bandwidth from the current page’s critical resources, and prefetched files land in the HTTP cache (if they’re cacheable) ready for the next navigation.

The trade-off: if the user never goes there, you’ve spent bytes for nothing — so apply it thoughtfully and avoid it on slow or metered connections.

<link rel="prefetch" href="/checkout/step-2" as="document">

Looking forward, the Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. is the modern successor to prefetch for predicting same-site navigations; web.dev notes it handles cases plain prefetch can’t (like non-cacheable navigations) and behaves more consistently across origins. prefetch remains useful and more broadly supported in the meantime.

Preload vs. prefetch vs. preconnect vs. dns-prefetch

Resource hints and Core Web Vitals

Here’s the part SEOs actually care about — which hint moves which metric:

• dns-prefetch / preconnect shave connection latency, which shows up as a faster start to loading your critical resources — feeding LCP and, before it, FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital..
• preload acts on LCP and FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. most directly by starting the fetch of the LCP image or a render-critical font/stylesheet earlier.
• prefetch doesn’t touch the current page’s Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. at all — it improves the next page’s LCP/FCP by having its resources already cached.

None of these directly affect INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good. or CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good., though getting fonts in earlier (via preload) can indirectly reduce layout shift from font swaps — that’s really a font loadingFont loading is how a browser fetches, applies, and renders custom web fonts — and specifically what it shows while the font file downloads. Those choices, controlled mainly by the CSS font-display property, directly affect two Core Web Vitals: LCP and CLS. topic, and render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. is the sibling article on the fetch-order side of the same problem.

Do resource hints help Google crawl or index my site?

No — and this is the single most important nuance to get right, because most content on this topic is vague about it.

In a February 2026 Search Off the Record episode, Google’s Gary Illyes explained why GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. largely ignores these hints: they solve browser and network latency problems that Google’s own crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. infrastructure doesn’t have. As reported by Search Engine Journal, Illyes said “it’s very helpful if you have like a crappy internet to do DNS Prefetching for example. In our case, we don’t need to because we can talk very fast to all the cascading DNS servers.” Jump to quote He made the same point about preload — “Same with preload. If we are not synchronous then we don’t particularly need to look at preload.” Jump to quote

So the correct causal chain is: resource hints → faster real-user experience → better Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. → one of several signals Google’s ranking systems use. Google’s own page experience documentation is explicit that there’s no single page-experience signal, that Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. are used by ranking systems alongside others, and that good CWV scores don’t guarantee a top ranking — relevance still wins over page experience. So it’s not nothing — but resource hints are a UX/performance tactic first, and their SEO value is entirely downstream and non-deterministic. Don’t sell them internally as “this helps Google read the page.”

Bing, for what it’s worth, has published no hint-specific guidance at all — its webmaster guidance references site speed generically. The browser-level benefits (faster loads, better vitals) apply the same regardless of search engine, so there’s no separate “Bing angle” to optimize for here.

Delivering hints over HTTP: the Link header and 103 Early Hints

Resource hints don’t have to live in your HTML. You can send them as an HTTP Link response header — Link: </hero.webp>; rel=preload; as=image — which is how server- and CDN-level implementations work. The most interesting version of this is 103 Early Hints: a preliminary HTTP status that lets an edge (like Cloudflare) send cached preload/preconnect Link headers before the origin server has even finished generating the full response — giving the browser a head start on connections and fetches while it waits. I cover the 103 status itself in my HTTP status codes guide, where I describe it as letting you preload resources to help LCP for Core Web Vitals.

Common mistakes

• Preloading too many resources — the cardinal sin; it creates bandwidth contention and can make the page slower overall.
• Preloading things the browser already finds early — an early <img> in the HTML doesn’t need preloading; you’re just spending a request slot.
• Missing as on preload — wrong priority and often a double download.
• Missing crossorigin on font preload/preconnect — a mismatched cache entry means the font downloads twice.
• Stale, unused preconnect tags — left behind after you removed the third-party script they were for, holding connections open for 10 seconds before the browser gives up.
• Ignoring the cost beyond your own page — unused hints don’t just waste your own bandwidth; they consume sockets and server/third-party capacity, and dns-prefetch/preconnect can reveal likely destinations to network observers. Browsers may also ignore, cancel, or limit hints under Save-Data, low-power, or support constraints — prefetch in particular is treated as optional and skipped for reduced-data users, so don’t assume a hint you shipped is actually running for every visitor.

How to test and audit

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. / PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — the “Preconnect to required origins” audit flags missing preconnects on key requests; treat it as a prompt to add a targeted one, not to carpet-bomb.
• Chrome DevTools → Network panel — the Priority column shows what the browser actually prioritized, and you can spot preloaded resources fetching twice (the as/crossorigin bugs).
• Check for unused preconnects — if a preconnected origin never appears as an actual request, remove the hint.

For the metrics these all feed, see Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. and Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.; the web performance tools article covers the measurement stack in depth.

AI summary

A condensed take on the Advanced version:

• Main hints, increasing browser cost: dns-prefetch (DNS only) → preconnect (DNS + TCP + TLS) → preload (mandatory fetch of a late-discovered current-page resource) → prefetch (lowest-priority speculative fetch for a future navigation). modulepreload is preload’s sibling for JS modules.
• preload is the only mandatory one — the browser must fetch it if it processes the tag — but that’s not the same as “automatically high priority.” Default priority still depends on resource type and browser; fetchpriority is the separate hint for actually raising it.
• Attribute matching matters: as is required on preload (or you get wrong priority + a double download); crossorigin is required for fonts; the eventual request also has to match on URL, type/media, credentials, integrity, referrerpolicy, and (for responsive images) imagesrcset/ imagesizes — mismatches cause duplicate or wrong-candidate fetches.
• Overuse is the dominant failure mode — “if everything is high priority, nothing is.” Unused hints also cost sockets/server capacity, can reveal likely destinations, and may be ignored under Save-Data constraints.
• LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image combo: preload + fetchpriority="high" is Google’s current recommendation.
• Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. mapping: dns-prefetch/preconnect cut connection latency (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.); preload acts on LCP/FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. directly; prefetch only helps the next page.
• SEO reality (Gary Illyes, Feb 2026): resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. don’t help GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawl or indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. — Google’s infrastructure lacks the browser latency these solve. Value is indirect: hints → faster UX → Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. → one of several ranking signals, not a guarantee. Bing has no hint-specific guidance.
• Delivery: HTML <link> or HTTP Link header; 103 Early Hints lets a CDN push cached hints before the origin responds.

Official documentation

Primary-source guidance from Google (Bing has no resource-hint-specific docs).

Google — web.dev

• Assist the browser with resource hints — the Learn Performance module covering all four hints and when to use each.
• Establish network connections early — preconnect and dns-prefetch, the 10-second unused-connection rule, and the crossorigin requirement for fonts.
• Preload critical assets to improve loading speed — the as attribute, late-discovered fonts/images, and the “if everything is prioritized, nothing is” warning.
• Optimize LCP — recommends pairing preload with fetchpriority="high" for the LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image.
• Prefetch resources to speed up future navigations — prefetch priority, HTTP cachingCaching stores a copy of a page or resource — in a browser, a CDN edge node, or a search crawler's own cache — so it can be served again without regenerating or re-downloading it. It isn't a direct ranking factor, but it feeds page speed and crawl efficiency. behavior, and the Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal. as its successor.

Google — Chrome / LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. & Search

• Preconnect to required origins (Lighthouse audit) — what the audit flags and why unused preconnects waste CPU.
• Understanding Core Web Vitals and Google search results — confirms CWVGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. is part of the page experience ranking signal (the indirect reason hints matter for SEO).
• Understanding page experience in Google Search results — confirms there’s no single page-experience signal and good Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. scores don’t guarantee top rankings.

Bing / Microsoft

• Bing Webmaster Guidelines — references site performance generically; no hint-specific guidance published.

Reference

• MDN — Using dns-prefetch.

Quotes from the source

On-the-record statements. Each link is a deep link to the quoted passage.

Gary Illyes, Google — why the crawlerA crawler — also called a spider or bot — is an automated program that fetches web pages, extracts their links, and queues new URLs to visit. Search engines use crawlers to discover and download content for their index. ignores resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. (Search Off the Record, Feb 2026)

• “It’s very helpful if you have like a crappy internet to do DNS Prefetching for example. In our case, we don’t need to because we can talk very fast to all the cascading DNS servers.” — Gary Illyes. Jump to quote
• “Same with preload. If we are not synchronous then we don’t particularly need to look at preload.” — Gary Illyes. Jump to quote

Patrick Stox — resource hints for LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. (Ahrefs)

• “DNS-prefetch has better support than preconnect.” — from my Largest Contentful Paint guide.
• “Early Hints don’t work on all browsers, so you may also want to preload the image.” — from the same LCP guide.

Resource hints — cheat sheet

Which hint, when

Syntax snippets

<link rel="dns-prefetch" href="https://cdn.example.com">
<link rel="preconnect" href="https://fonts.example.com" crossorigin>
<link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp">
<link rel="preload" as="font" type="font/woff2" href="/inter.woff2" crossorigin>
<link rel="prefetch" href="/next-page" as="document">

HTTP header equivalent (for CDN / 103 Early Hints)

Link: </hero.webp>; rel=preload; as=image
Link: <https://fonts.example.com>; rel=preconnect

Attribute rules

• as — required on preload (type + priority signal + cache matching).
• crossorigin — required for fonts on both preload and preconnect.
• type — helps the browser skip formats it can’t use (e.g. type="image/webp").
• Match the consumer, not just the tag — URL, as/destination, type/media, credentials, integrity, referrerpolicy, and (for responsive images) imagesrcset/imagesizes all have to line up or you get a duplicate/wrong fetch instead of a saved one.
• preload’s default priority is resource/browser-dependent, not automatically “high” — use fetchpriority to actually raise it.

Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. mapping

• dns-prefetch / preconnect → connection latency → LCP / FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.
• preload → LCP / FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. directly
• prefetch → the next page’s LCP/FCP only (not current-page CWV)

Resource hint myths and mistakes

Each one: why it’s wrong, and what to do instead.

Myth: “Resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. help Google crawl or indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. my page faster.” Wrong — per Gary Illyes (Feb 2026), Google’s crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. infrastructure doesn’t have the browser-side latency these hints solve; it resolves DNS internally and fetches resources through its own pipeline. Do instead: treat hints as a real-user performance tactic. The only SEO payoff is indirect, via Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data..

Myth: “More preloads = more speed.” Wrong — preloading a long list creates bandwidth contention, and the page can end up slower. “If everything is high priority, nothing is.” Do instead: preload only your two or three genuinely late-discovered, genuinely critical resources.

Myth: “Preload and prefetch are basically the same thing.” Wrong — preload is mandatory and high-priority for the current page; prefetch is speculative and lowest-priority for a future page. Mixing them up (using preload where you meant prefetch) makes the current page slower by competing with critical CSSCritical CSS is a performance technique that extracts the styles needed to render a chosen above-the-fold view, inlines them in the <head>, and defers the rest of the stylesheet. It speeds up first paint but is an advanced, optional optimization — Google says most sites don't need it — and carries real production risks around caching, CSP, and page state./JS. Do instead: preload for now, prefetch for next.

Myth: “You don’t need the as attribute; the browser figures it out.” Wrong — without as, the browser treats the request like a generic XHR, can’t set the right priority, and often downloads the resource twice. Do instead: always set as (e.g. as="image", as="font", as="style").

Myth: “Preconnect is always better than dns-prefetch.” Not quite — preconnect does the full handshake, which costs the browser more and has historically had narrower support. Do instead: preconnect only your few most critical origins; use dns-prefetch for the rest.

Myth: “Adding preconnect automatically means fonts will use that connection.” Wrong without crossorigin — omit it and the browser opens a second connection for the font anyway. Do instead: add crossorigin to any preconnect/preload you’ll use for fonts or other CORS fetches.

Before / after

Concrete fixes that follow from the guidance above.

1. LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image discovered too late

• Before: the hero image is set via a CSS background-image, so the browser doesn’t find it until it has downloaded and parsed the stylesheet. LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. is slow.
• After: <link rel="preload" fetchpriority="high" as="image" href="/hero.webp" type="image/webp"> in the <head> starts the fetch alongside the stylesheet — Google’s recommended LCP combo.

2. Font downloading twice

• Before: <link rel="preload" as="font" href="/inter.woff2"> — no crossorigin. The preload cache entry doesn’t match the CORS fetch the CSS triggers, so the font downloads twice.
• After: add type="font/woff2" and crossorigin; one download, surfaced early.

3. Over-preloaded page

• Before: a dozen preload tags for scripts, styles, and images “to be safe.” They contend for bandwidth and the page is slower than with none.
• After: keep preload for the LCP image and one render-critical font; drop the rest. Faster overall, because now the important things actually get priority.

4. Stale preconnect after a cleanup

• Before: a third-party chat widget was removed, but its <link rel="preconnect" href="https://chat.vendor.com"> was left behind. The browser opens the connection, holds it ~10 seconds, and closes it unused — wasted handshake capacity.
• After: delete the orphaned preconnect. Fewer competing connections at the critical moment.

Audit a proposed resource hint

Act as a web-performance reviewer. I will give you one HTML resource hint and the
matching Network-panel request details. Classify the hint as dns-prefetch,
preconnect, preload, or prefetch; state whether it targets the current page or a
future navigation; check required as, type, and crossorigin attributes; and identify
duplicate-fetch or bandwidth-contention risk. Do not recommend another hint until
you can explain why normal parser discovery is too late. Return: verdict, evidence,
smallest safe change, and a before/after validation test.

Prioritize candidates from a waterfall

Review this request waterfall and LCP element description. Propose at most three
resource hints. Prefer no hint when the browser already discovers a resource early.
For each candidate, give the exact reason it is late, expected request-timing change,
required attributes, risk if unused, and the Network/Lighthouse evidence that would
prove the change helped. Never treat a resource hint as a crawling or indexing fix.

Remove stale hints safely

Given this list of link rel resource hints and the requests from a cold page load,
identify hints that are unused, duplicated, or mismatched. Separate definite removals
from items that require another device/network test. Preserve only hints that serve a
named critical request. Return a removal checklist and rollback trigger; do not invent
performance savings.

Resource-hint release checklist

• The candidate solves a measured discovery or connection delay in a cold-load waterfall.
• preload targets a resource required by the current page; prefetch targets a likely future navigation.
• Every preload has the correct as value and an appropriate type where useful.
• Font preloads and preconnects include the matching crossorigin mode.
• The LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image is not both preloaded incorrectly and discovered through a competing source that causes a duplicate request.
• Preconnect is limited to the few origins used early in the load.
• No hint remains for a removed vendor, widget, font, or asset path.
• Slow-network testing shows critical resources move earlier without delaying higher-value work.
• A cold-load Network trace shows no duplicate fetches.
• The change is described as a user-performance optimization, not a GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawlingCrawling is how search engines use automated bots (like Googlebot and Bingbot) to discover URLs and download pages. A page has to be crawlable to be indexed, but crawling on its own isn't a ranking factor. or indexingStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. tactic.

Inventory hints and their attributes

Paste this into DevTools Console on the deployed page:

[...document.querySelectorAll('link[rel]')]
  .filter(link => ['dns-prefetch', 'preconnect', 'preload', 'prefetch'].includes(link.rel))
  .map(link => ({
    rel: link.rel,
    href: link.href,
    as: link.as || '(missing)',
    type: link.type || '(none)',
    crossorigin: link.crossOrigin || '(none)',
  }));

Review missing as values on preloads and missing CORS mode on font requests; other blank fields may be valid for that hint type.

Find preloads that fetched more than once

const preloads = [...document.querySelectorAll('link[rel="preload"]')]
  .map(link => new URL(link.href, location.href).href);

performance.getEntriesByType('resource')
  .filter(entry => preloads.includes(entry.name))
  .reduce((rows, entry) => {
    rows[entry.name] = (rows[entry.name] || 0) + 1;
    return rows;
  }, {});

Any count above one deserves inspection for an as, crossorigin, URL, or cache-key mismatch. A count of one does not by itself prove that the hint improved timing.

Tools for choosing and verifying hints

• Chrome DevTools Network panel: enable Priority and Initiator, disable cache, and inspect whether the target begins earlier or downloads twice.
• Chrome DevTools Performance panelThe Performance panel is Chrome DevTools' built-in, local profiler for recording and analyzing how a page loads and runs — CPU, main-thread work, rendering, network, and live Core Web Vitals. The recorded trace is local, lab data from your own browser — not what Googlebot sees — though the panel can optionally show real-user CrUX field data alongside it.: connect the request-timing change to FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. or LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. rather than declaring success from markup alone.
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. / PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking.: use preconnect and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. discovery diagnostics as candidate generators, then confirm each suggestion in the waterfall.
• Response headers view: verify HTTP Link headers and 103 Early Hints when the hint comes from the server or CDN rather than the HTML.
• A slow-network test profile: resource contention and over-preloading are easier to see under constrained bandwidth than on a warm, fast local connection.

Critical-resource timing

Test to run: Capture matched cold-load waterfalls before and after adding one preload or preconnect for a measured critical resource.

Expected result: The intended connection or request begins earlier, the resource is consumed once, and the associated FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital./LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. timing does not regress.

Failure interpretation: The browser already discovered it early, the attributes do not match the consuming request, or the hint competes with more important work.

Monitoring window: Compare repeated mobile and desktop lab runs immediately, then watch the relevant field vital through its reporting window.

Rollback trigger: Remove the hint if it causes duplicate fetches, remains unused, or produces a repeatable regression in the critical metric.

Hint hygiene after deployment

Test to run: Inventory all deployed resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. and match each one to an actual request in a cold load.

Expected result: Every preconnect serves an origin used early; every preload is consumed with matching request attributes; speculative prefetches map to a deliberate next-navigation rule.

Failure interpretation: A stale template or vendor removal left unused work, or a URL/CORS/type mismatch prevents reuse.

Monitoring window: Recheck after vendor, font, CDN, LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.-element, and template changes.

Rollback trigger: Remove any orphaned hint or revert a template change that sends invalid Link headers or breaks the page’s resource fetches.

Test yourself: Resource Hints

Five quick questions on preload, preconnect, dns-prefetch, and prefetch. Pick an answer for each, then check.

Resources worth your time

My related writing

• What Is Largest Contentful Paint (LCP) & How To Improve It — my most detailed treatment of resource hintsResource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch. in practice: early hints, preload, fetchpriority="high", and preconnect/dns-prefetch for cross-origin resources.
• 11 Types of HTTP Status Codes & Their SEO Impact — includes 103 Early Hints, the HTTP-level way to deliver preload/preconnect.
• The Beginner’s Guide to Technical SEO — where page performance fits in the bigger picture.
• Google PageSpeed Insights For SEOs & Developers — the tool that surfaces “Preconnect to required origins” and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. recommendations.

My speaking

• What’s Next for Page Experience (SMX Next 2021) — my deck with preconnect/dns-prefetch and preload-for-images examples.

From around the industry

• web.dev — Assist the browser with resource hints — Google’s canonical overview of all four hints.
• web.dev — Establish network connections early — preconnect and dns-prefetch in depth.
• web.dev — Prefetch resources to speed up future navigations — prefetch and the Speculation Rules APIThe Speculation Rules API is a Chromium browser API (Chrome/Edge 109+) that lets a site tell the browser which same-site pages to prefetch (download the HTML document) or prerender (fully load and render in an invisible tab) before a visitor clicks — so the next navigation can be near-instant. It's a browser-side performance feature for real users, not a crawling, indexing, or ranking signal..
• Chrome / Lighthouse — Preconnect to required origins — the audit and its cautions.
• DebugBear — Browser Resource Hints: preload, prefetch, and preconnect — a thorough, testing-driven walkthrough.
• Cloudflare — Early Hints and Cloudflare Docs — Early Hints — how 103 Early Hints delivers cached hints from the edge.
• KeyCDN — Resource Hints: What is Preload, Prefetch, and Preconnect? — a concise reference.
• MDN — Using dns-prefetch — the spec-level reference.

Resource Hints

Resource hints are <link> elements (or equivalent HTTP Link headers) that tell the browser to do network work — DNS lookups, connection setup, or fetching a resource — earlier than it would discover the need on its own. The main ones are dns-prefetch, preconnect, preload, modulepreload, and prefetch.

Related: Core Web Vitals, LCP, Render-Blocking Resources

Resource Hints

Resource hints let you give the browser a head start. Normally a browser only learns it needs a font, an image, or a third-party connection once it has parsed the HTML (and sometimes only after it has downloaded and parsed a CSS file). Resource hints move that discovery earlier by declaring the work up front — either as a <link> element in the <head> or as an HTTP Link response header.

There are four main hints, roughly in order of how much work the browser does up front:

• dns-prefetch — resolves a domain name to an IP address ahead of time. The cheapest hint; it only saves the DNS lookup step.
• preconnect — does the full connection handshake ahead of time: DNS lookup, TCP handshake, and TLS negotiation. It saves more time than dns-prefetch but costs the browser more, so it’s best reserved for your most critical cross-origin connections.
• preload — a mandatory fetch for a resource the current page definitely needs but that the browser would otherwise discover late (a font referenced inside CSS, or an LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. image). The browser must fetch it, but that doesn’t automatically make it high priority — default priority still depends on the resource type, and fetchpriority is the separate hint for raising it.
• modulepreload — preload’s counterpart for JavaScript modules; fetches a module into the browser’s module map using module-script rules.
• prefetch — a low-priority, speculative fetch for a resource likely needed for a future navigation, run at idle so it doesn’t compete with the current page.

All are suggestions the browser can ignore except preload and modulepreload, which the browser is obligated to fetch if it processes the tag. Their SEO value is indirect: they speed up the real-user browser experience, which feeds Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. — one of several ranking signals, not a guarantee — and they don’t help GooglebotGooglebot is Google's web crawler — the software that fetches pages so Google can index and rank them. It comes in two variants, Googlebot Smartphone (primary, under mobile-first indexing) and Googlebot Desktop, and runs an evergreen Chromium renderer. crawl or indexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. faster.

Related: Core Web Vitals, LCP, Render-Blocking Resources

Changelog