Performance
DNS prefetch
DNS prefetch is looking up a hostname before the page asks for a file from it. A `<link rel="dns-prefetch" href="//fonts.example.com">` hint starts the lookup early and saves the time the browser would otherwise spend later.
How it is measured
The saving equals the DNS lookup time for that host, usually 20 to 120 ms, but longer on a cold resolver or a mobile network. Check the DNS segment of the request in a waterfall with and without the hint.
It does only the lookup. It does not open a TCP connection or negotiate TLS, so it is cheaper than preconnect and works as a fallback for browsers that ignore preconnect.
Worked example
A blog loads fonts from one host and analytics from another, both discovered late in the HTML. In a waterfall the font host shows a 95 ms DNS bar starting at 640 ms. Adding `dns-prefetch` in the head moves the lookup to 40 ms, so the font request starts at 560 ms instead.
The analytics host is loaded after the load event, so a prefetch hint there gives no gain and is removed.
How it differs
DNS prefetch warms the lookup only. Preconnect also opens the TCP and TLS connection, saving more but costing more if the host goes unused. DNS itself is the system that maps names to addresses, and prefetching just asks the resolver earlier.
Common errors
Adding hints for hosts the page never uses. Listing ten domains and starving real requests. Expecting a gain for hosts already used in the first few ms. Forgetting crossorigin on a preconnect for fonts. Hinting a host that is already in the same domain as the page.
In practice
List the third-party hosts that matter for first paint, usually fonts and a CDN. Use preconnect for the one or two critical ones and dns-prefetch for the rest. Verify in a waterfall that the DNS segment actually shrank.