Glossary
dns-prefetch
`<link rel="dns-prefetch">` asks the browser to perform the DNS lookup for another origin ahead of time, so that the name is already resolved when a resource from it is requested. It is the cheapest of the resource hints: it opens no connection, transfers nothing, and costs a single DNS query. It saves only the resolution step, which is typically tens of milliseconds, and that is worth having on the origins a page will certainly use.
What it costs and what it saves
The cost is one DNS query per declared origin, which is a few hundred bytes and no connection.
The saving is the resolution time when the resource is eventually requested — commonly 20 to 120 milliseconds on a cold lookup, and effectively zero when the name is already cached.
Because it is so cheap, browsers tolerate more of these hints than of preconnects, and they can be declared for origins that matter less.
It saves nothing at all for the document's own origin, which was resolved before the HTML arrived.
It can also be sent as an HTTP header rather than a link element, which lets a server or an edge add the hint without the page being changed.
How it compares with preconnect
`preconnect` does the DNS lookup and also opens the TCP connection and completes the TLS handshake. It saves substantially more and costs substantially more.
`dns-prefetch` does the first step only.
The common pattern is to declare both for the same origin: the preconnect for browsers that honour it, and the prefetch as a fallback for those that have hit their preconnect limit.
For a page with many third-party origins, preconnecting to the two or three that matter and prefetching the rest is a reasonable allocation.
Where it applies
Analytics, advertisement, consent and tag-management origins, which are typically requested after the initial render and benefit from having their names ready.
Media and image origins used further down a page.
Origins referenced only by scripts, which the parser will never discover on its own.
It is not useful for origins that may not be used at all, where the query is spent for nothing — though the waste is small.
How to check it
List the distinct origins a page requests from. Anything beyond the document's own origin is a candidate.
In the network panel, a resource whose DNS phase is zero on a cold load has had its name resolved ahead of time.
A long list of prefetch hints is a symptom worth reading as such: a page contacting fifteen origins has a third-party problem that no hint addresses.
Removing an origin entirely always beats resolving it faster — self-hosting a font or a script removes both the lookup and the connection.
Place the hints early in the head, before the stylesheets. A hint discovered after a render-blocking resource has already been requested has lost most of the time it was meant to save.
Frequently asked questions
- Should I use dns-prefetch or preconnect?
- Preconnect for the two or three origins that matter most, dns-prefetch for the rest. Declaring both for the same origin is a common and harmless fallback.
- How much time does dns-prefetch save?
- The DNS resolution only, typically tens of milliseconds on a cold lookup and nothing when the name is already cached.
- Is there a limit on how many I should declare?
- It is cheap enough that a handful is unremarkable. A very long list usually indicates too many third-party origins, which is the real problem.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website