Preconnect vs DNS-Prefetch on Static Sites

Every new origin a page talks to costs a setup tax before the first byte: a DNS lookup, a TCP handshake and a TLS negotiation. On a fast desktop connection that is 50–100 ms; on a mobile network with 150 ms round trips it is 300–450 ms. preconnect pays that tax early, in parallel with other work; dns-prefetch pays only the DNS part. Both are one line of HTML, and both are frequently used in ways that make pages slower.

This guide measures both hints on a static blog that loads its hero images from an image CDN, runs a privacy-friendly analytics script from another origin and embeds occasional videos. It is part of Resource Hints and Navigation Speed.

Prerequisites

• A list of every origin your pages contact. Chrome DevTools' Network panel, grouped by domain, gives it in seconds.
• For each origin, when in the load it is first used and whether its resources are needed for first render.
• Lighthouse or WebPageTest to measure the effect of each change on LCP.

What Each Hint Does

A preconnected socket is not free: it holds a connection open, costs a TLS handshake's worth of CPU, and browsers close idle preconnects after roughly ten seconds. If nothing uses it by then, the work was wasted, and on a busy mobile load it may have delayed something that mattered.

The Test Site's Origins

The blog's post template contacted five origins besides its own:

Recipe: Hint by Criticality

Each origin gets the hint that matches when and whether it is needed:

<!-- critical, used in the first second: preconnect -->
<link rel="preconnect" href="https://img.example-cdn.net">
<!-- non-critical or late: dns-prefetch at most -->
<link rel="dns-prefetch" href="https://plausible.io">
<link rel="dns-prefetch" href="https://api.example-comments.com">
<!-- used only on interaction: nothing; connect when the facade is clicked -->

Two origins were removed from the list entirely rather than hinted. The fonts moved to the site's own origin — self-hosting eliminates the connection, which beats any hint, as covered in Self-Hosting Google Fonts to Eliminate Layout Shift. The video embed became a click-to-load facade, and the facade's click handler adds a preconnect on pointerdown so the connection starts about 100 ms before the click completes, following the pattern in Lazy-Loading YouTube Embeds on Static Sites.

facade.addEventListener('pointerdown', () => {
  const l = Object.assign(document.createElement('link'),
    { rel: 'preconnect', href: 'https://www.youtube-nocookie.com' });
  document.head.append(l);
}, { once: true });

For generator templates, emit the image-CDN preconnect only on templates that actually render an image from it. In Hugo that is a conditional in the head partial ({{ if .Params.hero }}); in Astro, pass a preconnect prop from the page to the layout; in Eleventy, set a front-matter flag the base layout reads.

Measured Impact

Five configurations of the post template, Lighthouse 12 mobile, median of five runs, preview deploy on Cloudflare:

Two findings generalise. Preconnecting to every origin was nearly useless: LCP improved by 80 ms while FCP got 90 ms worse, because seven early connections competed with the HTML and CSS. And the largest wins came from removing origins (self-hosting fonts) and from priority (fetchpriority), not from connection hints at all.

HTTP/2, HTTP/3 and Connection Coalescing

Modern protocols change the arithmetic in two ways worth knowing. First, HTTP/3 over QUIC combines the transport and TLS handshakes into one round trip (and zero for repeat visits with session resumption), so the tax a preconnect saves is smaller than on HTTP/1.1 or HTTP/2 over TCP — roughly one round trip instead of two or three. A preconnect to an HTTP/3 origin still helps, but by less; on the test blog the image-CDN preconnect saved 140 ms over HTTP/2 and 90 ms over HTTP/3.

Second, browsers coalesce connections: if two hostnames resolve to the same IP address and are covered by the same TLS certificate, an HTTP/2 or HTTP/3 connection opened for one can carry requests for the other. Serving images from img.example.com and pages from www.example.com through the same CDN with a wildcard or multi-name certificate often means the image requests reuse the page's connection and need no hint at all. Check in DevTools: the Connection ID column in the Network panel shows whether two origins share a connection. If they do, remove the preconnect — it can only open a redundant socket. This is another reason moving assets onto your own domain, even when they are served by a third-party CDN, tends to beat any hint.

Checking Hints in Production

Hints drift. A redesign moves the hero to a different CDN path; an analytics vendor changes domain; a preconnect stays in the layout for an origin nothing uses any more. Two checks keep them honest.

In the lab, Lighthouse's uses-rel-preconnect audit suggests origins that would benefit from a preconnect, and its console warnings list preconnects that were not used within ten seconds — assert both in Lighthouse CI, as set up in Setting Up Lighthouse CI for a Static Site. In the field, the Resource Timing API shows whether a request reused a preconnected socket: when connectStart equals connectEnd and domainLookupStart equals domainLookupEnd for the first request to an origin, the connection was already open. A tiny RUM beacon that reports this for the LCP image origin confirmed the hint was effective for 94% of page views; the remaining 6% were readers with the image already in cache, where no connection was needed.

Pitfalls & Rollback

• Preconnecting to every third party. Extra early connections compete with critical requests. Preconnect only to origins used for first render.
• Missing crossorigin for CORS fetches. A preconnect without it opens a non-CORS connection that font and module requests cannot reuse.
• Preconnecting to your own origin. The HTML request already opened that connection. It does nothing.
• Duplicating hints in headers and HTML. A Link response header and an identical <link> tag are harmless but confusing; keep hints in one place so audits find them.
• Hints in a global layout. An image-CDN preconnect on templates without images is a wasted connection on every view. Emit hints per template.
• Rollback: hints are single <link> lines. Removing one restores default behaviour on the next deploy with no other effect.

Conclusion

On static sites, the best connection hint is usually no connection: self-host fonts and scripts so they share the page's origin. For the one or two third-party origins that serve first-render resources — typically an image CDN — use preconnect. For everything later or optional, use dns-prefetch or nothing, and connect on interaction for click-to-load embeds. On the test blog that combination, plus fetchpriority on the hero, cut LCP from 2.46 to 1.74 seconds, while preconnecting to every origin had barely moved it.

FAQ

What does preconnect actually do?

It performs the DNS lookup, TCP connection and TLS handshake to an origin before any request needs it. When the first real request to that origin happens, the connection is already open, saving one to three round trips.

When is dns-prefetch the better choice?

For origins used later in the page or only sometimes, such as analytics or a comments service. dns-prefetch costs almost nothing and saves the DNS lookup, while an unused preconnect wastes a connection and CPU time.

Do I need crossorigin on preconnect?

Only if the resources you will fetch from that origin are requested in CORS mode, such as web fonts or scripts with the crossorigin attribute. The browser keeps separate connections for credentialed and anonymous requests, so a mismatched preconnect is not reused.

Why did adding preconnects make my page slower?

Each preconnect competes for the network and CPU during the most critical part of the load. On mobile, opening several extra connections early can delay the HTML, CSS or LCP image. Keep preconnects to the one or two origins needed for first render.

Related

• Parent: Resource Hints and Navigation Speed — all the hints and when each applies.
• Auditing Unused Preloads — the same discipline for preload.
• Building an Image CDN Pipeline for Static Sites — the origin most worth preconnecting.
• Self-Hosting Analytics to Cut Third-Party Requests — removing an origin instead of hinting it.
• Reducing LCP from Hero Images on Static Sites — the rest of the hero-image work.