preconnect, dns-prefetch and preload on 27 homepages: 650 hints, three sites with none

FIELD TEST · 2026-08-24 · 27 homepages · single crawl · link rel hints only

Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-24 with a browser user agent. We read the delivered HTML and recorded every <link> whose rel is preconnect, dns-prefetch, preload, modulepreload, prefetch or prerender, with its href, as and whether the crossorigin attribute is present.

Across 27 homepages we counted 650 resource hints. The median site ships five; one ships 263. preconnect accounts for 49 of the 650 and appears on 19 sites, while dns-prefetch appears on only five. Three homepages ship no hints at all, and three ship a preconnect pointing at their own origin.

How we measured it

One HTTP request per site, no rendering, no retries. Inclusion was fixed before the run: status 200, body at least 10,000 bytes, body containing <body. Three of the 30 failed — stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 27, the same three exclusions as previous batches.

Hints injected by script after load are invisible to us, so every number here is a floor, not a total. We did not measure whether any of these hints made a page faster. That needs real connection timings on real networks, and this was one fetch per site.

650 hints, and four of the six keywords are unused

The spread is extreme rather than typical. Mean per site is 24.1 and median is 5, because one site carries 40% of the sample on its own.

linear.app ships 263 hints, of which 258 are modulepreload lines for its own JavaScript chunks. github.com is second with 80, www.nytimes.com third with 70. At the other end, www.canva.com, www.netlify.com and news.ycombinator.com ship none — and Hacker News does not ship much of anything, which is the point of Hacker News.

The preconnect that connects to nothing

Three homepages — stripe.com, www.notion.com and www.bbc.com — send <link rel="preconnect" href="/" crossorigin="anonymous">. That points at the origin the browser is already talking to. MDN's preconnect reference, read on 2026-08-24, is direct about it: "It has no benefit on same-origin requests because the connection is already open."

All three tags carry a data-next-font attribute, so a person did not type them. The framework emitted them. This is worth knowing because it changes what to do about it: there is nothing to fix in your own markup, and nothing gained by hunting for it either.

A resource hint is a promise that a request is coming. If no request follows, the hint has cost a connection slot for nothing.

dns-prefetch has almost disappeared, and preconnect took its place

Only five sites use dns-prefetch: github.com, railway.com, stripe.com, techcrunch.com and www.theverge.com. Two of them, stripe.com and github.com, declare both hints for the same hosts — four hosts and two hosts respectively. That is the documented fallback pattern, not a mistake.

MDN's guidance explains why the split exists: "If a page needs to make connections to many third-party domains, preconnecting them all can be counterproductive. The <link rel="preconnect"> hint is best used for only the most critical connections. For the others, just use <link rel="dns-prefetch"> to save time on the first step — the DNS lookup."

By that reading, 19 sites using preconnect against five using dns-prefetch is the wrong ratio for a panel where the median site opens hints to more than one third-party host. We don't know whether any of them is measurably slower for it. We did not time them.

What the preload lines actually point at

Of the 169 preload lines, none is missing the as attribute — which is the failure MDN warns about, since as is what lets the browser set the right priority, the right Accept header and the right content security policy.

The font row is the one we expected to be a mess. MDN states that "font and fetch preloading requires the crossorigin attribute to be set", and a font preload without it opens a second, unusable connection. Every one of the 29 font preloads in this panel has it.

We got that answer wrong on the first pass. Our parser read crossorigin by value, and both crossorigin on its own and crossorigin="" are legal ways to write the anonymous mode — so nine correct tags looked like nine broken ones. The fix was to test whether the attribute is present rather than what it holds. If you write your own checks against markup, boolean attributes are where they break.

What this means for you

Resource hints are cheap to add and easy to leave behind, which is how a page ends up with duplicates. We found four: www.framer.com declares the same preconnect to fonts.gstatic.com twice, www.shopify.com does the same for cdn.shopify.com, and www.nytimes.com and linear.app each repeat preload lines.

• Keep preconnect for the two or three hosts on the critical path, and use dns-prefetch for the rest.
• Give every preload an as value, and give every font preload crossorigin.
• Don't preconnect to your own origin. The connection is already open.
• Don't preload something the page might not use. An unused preload is a wasted request.

Hints are the last thing to tune, not the first. If the document itself is slow to arrive, none of this helps — time to first byte across the same panel is the number to look at before this one, and the gap diagnosis path starts here if you want the whole chain rather than one header.

Common questions

How did you measure this?

One request per homepage on 2026-08-24, browser user agent, no JavaScript execution. We parsed every <link> element in the delivered HTML and kept the six hint rel values, recording href, as, and the presence of crossorigin and imagesrcset as attributes.

What is the difference between preconnect and dns-prefetch?

dns-prefetch resolves the hostname. preconnect resolves it and then completes the TCP and TLS handshakes as well. Preconnect saves more time and costs a connection, which is why MDN suggests reserving it for the most critical hosts.

Does preconnect help SEO?

Not on its own, and we can point to no documentation saying otherwise. It affects how quickly a browser can start fetching a subresource, which shows up in field performance data, which is a small ranking input. That is three steps of indirection, and we would rather write it out than compress it into a claim.

Why do 23 image preloads have no href?

They use imagesrcset and imagesizes instead, which is the responsive form of an image preload. It is correct markup, not a missing attribute. Our count treats them as image preloads with no single-URL target. For the related question of when images should load at all, see loading lazy versus eager across 1,677 homepage images.