How this was measured
On 2026-10-17 we requested the homepage of each of the same 78 hand-picked domains our other surveys use — news, commerce, SaaS, developer tooling, social, streaming, reference, SEO, education, finance, cloud, local and government — and parsed every <link> tag in the HTML we got back, keeping the six rel values that are resource hints: preconnect, dns-prefetch, preload, prefetch, prerender and modulepreload. Each request identified itself as a survey crawler and was attempted directly first, then through a local proxy; 42 domains answered on the direct path and 21 needed the proxy. We also read the HTTP Link response header of every page, because a hint can be sent by the server instead of written in the markup.
63 of 78 returned a readable homepage (80.8%). The other 15 are counted as undecidable, not as absent: no response at all from nytimes.com, reuters.com, washingtonpost.com, etsy.com, quora.com and coinbase.com; 202 from amazon.com and booking.com; 403 from ebay.com, stackoverflow.com, npmjs.com, searchengineland.com, yelp.com and nih.gov; 406 from uber.com. Across those 63 homepages we found 811 hint tags, a median of 5 per site.
Four parsing decisions shaped every number below, and three of them changed an answer. Inline JavaScript is masked before parsing. The word preload appears 110 times in youtube.com's inline config and netlify.com defines a warmConnections() function that builds preconnect tags at runtime; neither is a hint in the HTML, and counting them would have invented two enthusiastic adopters. Attribute values do not have to be quoted, so a parser that insists on quotes silently drops them. crossorigin is a boolean attribute and presence is all that matters — our first pass looked for a value and reported 22 font preloads as broken when in fact they were written correctly as bare crossorigin; every one of those was checked against the raw tag before we discarded the finding. And the internal/external split is decided by registrable domain, not by hostname, so avatars.githubusercontent.com counts as github.com's own.
Finding 1: two hints do the work, four are close to extinct
49 of 63 homepages (77.8%) use at least one resource hint, and the 811 tags break down very unevenly. preload leads with 418 tags across 40 sites (63.5%) and preconnect follows with 130 tags across 37 (58.7%). Everything else is a rounding error: dns-prefetch 60 tags across 17 sites (27.0%), modulepreload 200 tags across 4 (6.3%), prefetch 3 tags across 2 (3.2%) and prerender zero, on all 63.
The modulepreload number is not a trend, it is four sites: github.com with 86 tags, gitlab.com with 79, shopify.com with 30 and archive.org with 5. Pooled totals are misleading throughout this article for exactly that reason, which is why every rate is reported per site as well. prefetch is two tags from who.int and one from moz.com. prerender — the hint that asks the browser to render a whole page in the background — has no users here at all, which matches what happened to it: Chrome deprecated it in favour of the Speculation Rules API, and whatever remains of it is not on any homepage we could read.
The typical site also does not combine them. The median homepage uses 2 of the 6 kinds, and 16 sites use exactly one — bbc.com, go.dev and wikipedia.org preconnect and nothing else; netflix.com, nodejs.org and airbnb.com preload and nothing else; docker.com and harvard.edu only dns-prefetch. 30 sites use both preload and preconnect, 10 preload without preconnect, and 7 preconnect without preload.
Finding 2: the median is small and the tail is enormous
Per-site counts look nothing like the pooled picture. Among the sites that use preconnect, the median is 2 origins and the maximum is 17 (spotify.com, which preconnects to eight of its own API and dealer hosts, plus ad and CDN origins). Nine sites preconnect to more than four origins: spotify.com 17, cnn.com 12, target.com 9, bloomberg.com 7, semrush.com 7, theguardian.com 5 and three others.
preload is even more skewed: median 4, maximum 72 (pinterest.com), with notion.so 49, airbnb.com 42, searchenginejournal.com 33, bloomberg.com 27 and target.com 22. 19 of the 40 sites that preload, preload more than four resources. The advice you usually read — preconnect to two or three origins, preload the handful of things that block render — is describing the median site in this sample accurately, and describing the top quartile not at all.
Two-thirds of what gets preloaded is not the site's own. 267 of the 399 preloads with a resolvable host (66.9%) point at a different registrable domain, and 85 of the 130 preconnects (65.4%) do the same. Resource hints are, in practice, a third-party warming mechanism.
Finding 3: dns-prefetch survives as a companion, not a choice
dns-prefetch is the oldest hint here and the one the newer preconnect was supposed to replace, since preconnect does the DNS lookup and the TLS handshake. What we found is not replacement but pairing: 34 origin pairs across 9 sites declare both for the same host — cnn.com does it 12 times, stripe.com 4, theguardian.com 4, wise.com 3, twitch.tv 3 and vimeo.com 3.
That pairing is a defensible pattern rather than a mistake: dns-prefetch is still the fallback for browsers that ignore preconnect, so writing both costs one line and covers one extra browser generation. What is harder to defend is the reverse: 3 sites use dns-prefetch and never preconnect — docker.com, yoast.com and harvard.edu, all three of them engineering-led sites, are doing the cheap half of the job on a browser population that is overwhelmingly modern.
Finding 4: the one rule everybody gets right, and the single tag that breaks it
MDN states that font and fetch preloads require the crossorigin attribute to be set, because fonts are fetched in anonymous CORS mode — get it wrong and the file downloads twice. All 77 font preloads across 29 sites carry crossorigin. The miss rate is zero. That is the cleanest result in the whole survey, and it is worth noting that it only looked like a 29% failure rate until we printed the raw tags and found 22 of them written as a bare boolean crossorigin with no value.
The Google Fonts split is right too. Four sites preconnect to fonts.gstatic.com — bloomberg.com, vimeo.com, semrush.com and who.int — and all four put crossorigin on it, while the three that also preconnect to fonts.googleapis.com (the stylesheet, not the font files) leave it off. That is precisely the documented recommendation, executed correctly by everyone who tried.
Overall, 56 of the 130 preconnects (43.1%) carry crossorigin — which is not a defect rate, since most preconnect targets are not CORS requests.
Exactly one preload in 418 is missing its as attribute, and it is atlassian.com: <link rel="preload stylesheet" href="…/atlassian-fonts.css">. MDN lists as as one of the two attributes a preload needs, alongside href; without it the preload has no destination, so the browser cannot match it to the later stylesheet request, and the console says so. The as values that are present distribute as script 132, style 113, image 92, font 77, fetch 3 — and not one of them falls outside the specification's list.
Finding 5: most preconnects warm an origin the HTML never mentions
This is the finding that explains why the counts are what they are. Of the 110 distinct origins that these 37 sites preconnect to, 89 (80.9%) appear nowhere else in the page's HTML — no script, image, iframe or stylesheet on the page points at them. We bucketed those 89 by hostname: 36 are advertising, analytics, CDN, consent or bot-defence hosts that JavaScript injects after load, which is exactly the case a preconnect exists for. You cannot discover tpc.googlesyndication.com by parsing HTML, so you warm it in advance.
The other 53 are more interesting, because they are application surface rather than ad surface: target.com preconnects to gsp.target.com, api.target.com, redsky.target.com, cdui-orchestrations.target.com and carts.target.com — five API hosts the homepage will call the moment a user does anything. spotify.com preconnects to apresolve.spotify.com, clienttoken.spotify.com, api-partner.spotify.com, spclient.wg.spotify.com and four more of its own service hosts. asana.com preconnects to api.ipify.org, a geolocation lookup. On these pages the hint is the only trace in the markup of where the application actually goes.
That produces a lopsided ratio. The median site preconnects to 2 origins while actually referencing 3 third-party origins in its HTML, and 12 sites preconnect to more origins than the page references at all — spotify.com 16 versus 9, target.com 7 versus 4, archive.org 2 versus 0, tumblr.com 1 versus 0. Read as a rule: the hint list is not a summary of the page, it is a schedule of what the page will do next.
Finding 6: a second channel that almost nobody mentions
13 of the 63 homepages send any Link response header, and 5 of them put resource hints in it. The heaviest users are stanford.edu (10 rel=preload entries), squareup.com (5 preconnects and 3 preloads), cloudflare.com (2 preconnects and 3 preloads), airbnb.com (1 preconnect and 2 preloads) and yoast.com (1 preconnect, 1 dns-prefetch and 2 preloads). theguardian.com sends 10 preconnects and 3 prefetches this way on top of what is in its HTML.
Nothing in the HTML-only counts would tell you that, and it is why this survey read headers as well as markup. It also exposes a measurement trap we hit ourselves: netlify.com shows zero hints in its HTML and zero in its headers, which reads as "does not use resource hints" — until you look at the JavaScript, where a warmConnections() method builds preconnect tags for youtube-nocookie.com, google.com and two DoubleClick hosts at runtime. Zero tags is not the same as zero warming.
The same headers also carry things that are not hints at all: api-catalog on netlify.com, vercel.com and cloudflare.com, plus ai-catalog and agent-skills on vercel.com. If you audit headers for hints, expect to filter.
Finding 7: 14 homepages with nothing at all
14 of the 63 homepages carry no resource hint in either channel: trello.com, reddit.com, linkedin.com, python.org, rust-lang.org, youtube.com, mozilla.org, w3.org, wikimedia.org, screamingfrog.co.uk, mit.edu, paypal.com, netlify.com and cdc.gov. Two of those are undecidable rather than decided — reddit.com (8 KB) and paypal.com (8 KB) returned pages with zero links on them, which is a shell or an interstitial, not a homepage.
The rest are a genuine mix. python.org, mozilla.org, w3.org, wikimedia.org, mit.edu and cdc.gov are pages with no third-party dependencies to warm and no render-blocking resource to preload; the hint would do nothing. youtube.com is a 950 KB single-page application whose own configuration mentions preloading 110 times but which ships no hint tag — and netlify.com, as above, warms from script. Absence here is a statement about architecture, not about carelessness.
Finding 8: fetchpriority is spreading, and mostly being used to say "later"
135 hint tags across 17 sites carry fetchpriority — a fifth of everything we counted. The dominant value is low: pinterest.com puts fetchpriority="low" on 67 of its 72 preloads, shopify.com on 26 modulepreload tags and github.com on 13 more. The pattern is a site that preloads a lot and then tells the browser which of it to stop queueing ahead of real content.
The high end is small and specific: walmart.com on 3 font preloads, coursera.org and stripe.com on 4 each, x.com and airbnb.com on 1 each, and shopify.com on 1. walmart.com also uses fetchpriority="auto" twice, which is the value you write when you need to undo an inherited priority.
What to ship
Use preload and preconnect; treat the rest as special cases. They are the two hints with majority adoption here, and prerender has none.
Preconnect to the origins your page will call, not the ones it already mentions. 81% of the preconnected origins in this sample appear nowhere in the HTML, and that is the point: the hint is how you schedule what the parser cannot see.
Pair dns-prefetch with preconnect or drop it, never ship it alone. Nine sites pair them; the three that ship it alone are doing the cheaper half.
Put crossorigin on every font preload, in any form — bare, empty or anonymous. All 29 sites here get it right, and the failure mode is a double download.
Never write a preload without as. One in 418 does, and that tag cannot do its job.
Check the response headers before concluding anything. Five sites in this sample put hints in Link headers only, and one site warms connections from JavaScript with no tag anywhere: curl -sI https://example.com/ | grep -i '^link:' shows the first, and only reading the bundle shows the second.
To assemble head tags without any of them drifting apart, the meta tag generator produces the title, description, canonical, robots and icon tags from one input, and the robots.txt tester covers the file that governs crawling rather than loading.
Limitations
Homepages only, 63 of them, one snapshot. Everything was fetched on 2026-10-17 with a crawler identity. WAFs answer differently per client, an article page has a completely different resource profile from a homepage, and a site that A/B tests its head will look different on the next request.
Server-rendered HTML plus response headers, nothing more. Any hint created by JavaScript after load is invisible to this method, and that is not a small category: netlify.com builds its preconnects from script and youtube.com builds everything from script. Our zero counts are floors, not measurements. We did not capture 103 Early Hints, which is a third channel for the same information.
"Not referenced in the HTML" is a weak statement. It means the hostname string does not appear outside the hint tag in the markup we received. A resource loaded from a relative path, a CSS background image or a dynamic import is invisible to that test, so the 80.9% is an upper bound on genuinely unused hints rather than a count of them.
We counted attributes, not outcomes. Whether a preloaded file was actually used, whether a warmed connection saved a round trip, and whether the 72 preloads on pinterest.com helped or hurt, are questions this method cannot answer. Nothing here is a performance measurement; it is a census of what is written.
Reproduce it
The script and the shared domain list ship with this site. node scripts/survey-resource-hints.mjs fetches all 78 homepages and stores the HTML and response headers; --report re-parses and re-derives every number from the stored HTML without touching the network, which is how the boolean-crossorigin fix was applied after the fetch; --evidence prints the original <link> tag or Link header behind every verdict — that is what caught the 22 false font failures and confirmed the single missing as. Our link rel, favicon, heading and indexing directive surveys run the same domain list from other angles.