Saving round trips before the browser even asks

Every resource your page fetches from a third-party origin requires a connection to be established first. That setup involves DNS resolution, a TCP handshake, and, for HTTPS origins, a TLS negotiation. Each of those steps is a round trip between browser and server, and under real network conditions a single round trip can be costly. Completing this work before the browser actually needs the resource is one of the more direct ways to shrink perceived latency.

Two resource hints cover this: <link rel=preconnect> and <link rel=dns-prefetch>. Neither is a mandatory instruction—browsers can ignore or partially honor them—but they signal intent early enough for the connection work to overlap with other page processing.

Starting the full connection with preconnect

Adding rel=preconnect to a <link> tells the browser the page intends to open a connection to another domain and to start that process as soon as possible. When the browser later requests a resource from that origin, the connection setup is already done and the resource loads without the usual multi-round-trip delay.

The hint is declared in the document <head>:

<link rel="preconnect" href="https://example.com">

Measured gains from early connections to important third-party origins typically land in the 100–500 ms range. That may not sound like much, but it has a direct effect on how quickly meaningful content is available to the user.

There is no need to preconnect to your own origin. The hint is only effective for other domains.

Where preconnecting earns its keep

Two scenarios benefit most. The first is when you know the origin a request will go to but not the exact resource path—versioned dependencies on a CDN are a common case, as are images served from an image CDN where the final URL depends on viewport or runtime feature checks. The browser still waits for the resource request before downloading anything, but the connection phase is already handled.

The second is streaming media from a separate origin. If your page needs scripts loaded and ready before it can process the stream, preconnecting to the media origin means fetching can begin after a single round trip once those scripts are in place.

Handing over the hint

Besides a <link> tag, preconnect can be initiated via the Link HTTP header:

Link: <https://example.com/>; rel=preconnect

Some resource types are requested in anonymous mode—fonts are a prominent example. For those, the crossorigin attribute is required on the hint:

<link rel="preconnect" href="https://fonts.example.com" crossorigin>

Without crossorigin, the browser only performs the DNS lookup and aborts the rest of the connection setup.

Covering the low-cost part with dns-prefetch

When a page touches many third-party domains, preconnecting to all of them is counterproductive—each open connection consumes resources and bandwidth. Reserve preconnect for the most critical connections and fall back to <link rel=dns-prefetch> for the rest. DNS resolution is the first step of connection setup and typically takes 20–120 ms, so resolving names early still removes meaningful delay for secondary origins.

DNS prefetch is declared the same way:

<link rel="dns-prefetch" href="https://example.com">

Browser support for dns-prefetch is broader than for preconnect, which makes it a practical fallback for browsers that don't support the stronger hint. If you combine both for that purpose, keep them in separate <link> tags. Putting dns-prefetch and preconnect in the same tag triggers a Safari bug that cancels the preconnect.

The connection to Largest Contentful Paint

Both hints shorten the time to fetch a resource from another origin, and that matters for LCP. The ideal case is an LCP resource that is immediately discoverable, ideally with a fetchpriority="high" attribute so the browser fetches it early. A preload link with the same fetchpriority value is the next best option when the asset is known in advance but not discoverable in the document order.

When the exact LCP resource can't be known until later in the page load, preconnect to the cross-origin host reduces the penalty of that late discovery as much as possible. It is worth remembering that preconnect costs less bandwidth than preload, but it is not free: TLS certificate exchanges consume bytes, and preconnecting to too many origins can create bandwidth contention. Use it sparingly.

In practice, prefer preconnect for the few origins that matter most, use dns-prefetch for the long tail, and validate the results with real-world measurements.