Resource Hints With a CDN: preconnect, dns-prefetch, preload

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.

What resource hints actually remove from the critical path

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.

Only preconnect and 103 Early Hints delete real wall-clock network time; preload and prefetch reorder work the browser was going to do anyway.

preconnect vs dns-prefetch: which resource hints earn their slot

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.

Why preconnect to your CDN hostname is often a no-op

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.

Which resource hints survive HTTP/2 connection coalescing

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.

Does preload cut time to first byte?

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.

Attaching resource hints at the edge instead of the origin

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:

1. For any origin serving CORS-mode subresources, add the crossorigin parameter to the preconnect. Without it the browser opens a second, credentialed connection and you pay the handshake twice.
2. Font preloads need as set to font, type set to font/woff2, and crossorigin set to anonymous. Fonts are always fetched in CORS mode, so a preload without crossorigin produces two full downloads of the same file.
3. Prefetched responses must be cacheable. If the edge returns no-store or a Vary the prefetch cannot match, the bytes are discarded. Segment your edge logs by the Sec-Purpose request header so speculative fetches do not distort hit-ratio reporting.

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.

Trade-offs and observability gaps

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.

Verify this on your own stack

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.

FAQ: resource hints, preconnect and CDN delivery

How many preconnect hints should a page use?

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.

Does dns-prefetch still help in 2026?

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.

Can a CDN add resource hints without changing the HTML?

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.

Run the 30-minute version of this experiment

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.