Resource hints do not make a CDN faster. They remove waiting the browser would otherwise do serially. A preconnect eliminates a DNS lookup plus a TCP and TLS handshake against one origin, worth roughly 100–300 ms on a cold third-party host in 2025 mobile field measurements. A dns-prefetch removes only the resolution step, typically 20–120 ms. A preload removes discovery latency, not network latency. None of these resource hints change the document's time to first byte. Only 103 Early Hints, emitted by the edge while the origin is still generating the page, touches that number.
Each hint targets a different phase of the fetch lifecycle. Confusing them is why teams ship twelve preconnects and measure nothing. The phases are: resolve, connect, discover, fetch, and the origin's own think time. A hint that targets a phase you are not blocked on returns zero.
| Hint | Phase removed | Typical saving (2025 ranges) | Main failure mode |
|---|---|---|---|
| preconnect | DNS, TCP or QUIC, TLS for one origin | 100–300 ms mobile, 30–80 ms fixed line | Idle socket discarded if unused within about 10 s in Chromium |
| dns-prefetch | Resolution only | 20–120 ms on a cold resolver, near zero on a warm one | Ignored or deprioritized once the connection limit is reached |
| preload | Discovery and priority assignment | 0 ms for preload-scanner-visible assets, up to several hundred ms for CSS-nested or JS-injected ones | Wrong as value or missing crossorigin causes a full second download |
| prefetch | The next navigation's entire fetch | Full round trip plus transfer, if the guess is right | Pure waste on a wrong guess or a non-cacheable response |
| 103 Early Hints | Origin think time | Whatever the origin spends between request and first byte, commonly 80–400 ms | Requires an edge that forwards the informational response intact |
Only preconnect and 103 Early Hints delete real wall-clock network time; preload and prefetch reorder work the browser was going to do anyway.
On a cold third-party origin the browser must finish DNS resolution, a transport handshake and a TLS 1.3 handshake before the first byte of that asset moves, and in 2025 mobile field data that chain typically costs 100–300 ms. A preconnect issued at least 200 ms before the asset is requested removes the entire chain from the critical path, while dns-prefetch removes only the resolution portion, usually 20–120 ms. Chromium discards an unused preconnected socket after roughly 10 seconds, so a hint fired too early is simply a paid handshake with no return.
Practical rule: preconnect the two or three origins you are certain will be hit above the fold. Use dns-prefetch as the cheap fallback for everything else, including origins that may never be used. Each preconnect costs a handshake, CPU for the key exchange, and on cellular a radio wake.
If the document and its assets come from the same host, the connection already exists by the time the parser sees the hint. The preconnect resolves to a cache hit in the connection pool and saves nothing.
HTTP/2 and HTTP/3 clients reuse an existing connection for a second hostname when the resolved address set intersects and the presented certificate covers both names. Most CDN deployments issue one certificate covering the apex, www and the asset subdomain, all announced over the same anycast address. Preconnecting to a second hostname on that same CDN gains nothing, and domain sharding across cdn1 and cdn2 actively costs you the coalescing benefit you already had.
Where preconnect still pays inside a CDN topology: a separate media or download hostname on a different certificate, an object storage endpoint fetched directly by the client, and any third-party you do not control. Verify by comparing the certificate subject alternative names and the resolved addresses. If both match, drop the hint.
No. Preload cannot affect document time to first byte, because the document request is already in flight before any hint in that document is parsed. Preload only moves subresource discovery earlier and raises fetch priority. The measurable effect shows up in largest contentful paint and in the start time of the preloaded asset, not in server response timing.
The one mechanism that does compress document-level waiting is the 103 informational response defined in RFC 8297. The edge returns 103 with Link headers carrying preconnect and preload targets while the origin is still assembling the final response. The client starts handshaking and fetching critical CSS during origin think time. On origins with 150–400 ms server processing, vendor-published 2023–2025 measurements put the first-paint improvement in the 100–300 ms band. On an edge-cached page with 20 ms TTFB, the gain is approximately zero, because there is no think time to fill.
Hints belong in response headers when you want them applied per path without a template deploy. The header form is Link, with the target URI enclosed in angle brackets as RFC 8288 requires, followed by a rel parameter. Three details decide whether it works:
Being able to set and revert these headers per path at the edge, rather than through an origin release, shortens the experiment loop from days to minutes; BlazingCDN exposes edge response-header and caching controls at that granularity, as do most providers with rule-based configuration.
Preload competes for bandwidth with the document itself. Chromium assigns preloaded scripts and styles high priority, so five preloads on a constrained uplink can delay the HTML body they were meant to accelerate. Keep preload to render-blocking assets the preload scanner cannot see.
The observability gap is real: Resource Timing does not report whether a hint was honoured. You infer it. A reused connection shows connectStart equal to connectEnd and domainLookupStart equal to domainLookupEnd for that entry. That is the signal, and it is indirect.
Pull Resource Timing entries from real-user monitoring and compute, for third-party subresources only, the share of requests where connectEnd minus connectStart exceeds 0 ms. Multiply that share by your p75 handshake cost to get the millisecond budget preconnect can recover. Then check nextHopProtocol on your asset hostname: if it is h2 or h3 and matches the document's, coalescing is already active and the hint is decorative. Finally, confirm whether your edge forwards 103 responses before planning any Early Hints work.
Two to four, covering only origins requested during the first viewport render. Each preconnect consumes a socket, a TLS key exchange and, on cellular, a radio wake. Chromium discards unused preconnected sockets after roughly 10 seconds, so hints for origins hit later in the session are wasted cost rather than a speedup.
Yes, but narrowly. dns-prefetch saves only resolution time, typically 20–120 ms on a cold resolver and close to zero on a warm one. Its value is that it is cheap enough to apply speculatively to origins that may never be used, which is exactly where preconnect would be a waste.
Yes. Hints can be delivered as Link response headers set at the edge, which browsers treat equivalently to markup hints. This lets you add preconnect or preload for a specific path, measure it, and revert without an origin deploy. The same mechanism carries hints inside a 103 Early Hints response.
Take one high-traffic template. Count the distinct origins requested before largest contentful paint, then check certificate coverage and resolved addresses for each. Drop every preconnect pointing at an origin that already coalesces with the document connection, keep the two that do not, and hold everything else at dns-prefetch. Re-measure p75 LCP and the asset start times over a week of real-user data, not lab runs. If the delta is under 20 ms, your bottleneck was never connection setup, and the next place to look is origin think time and edge hit ratio.