Preconnect

Preconnect is a browser resource hint that asks the user agent to establish an origin-level connection ahead of need. It is expressed as an HTML link relation (rel="preconnect") or via an HTTP Link header and is advisory: the browser may prioritize or ignore it based on heuristics.

Preconnect requests that the browser proactively set up an origin-scoped connection (scheme, host, port) before any dependent resource is discovered. Unlike preload, it does not fetch a specific file; it prepares the underlying transport so the first subsequent request to that origin can send bytes without waiting for DNS, TCP, or TLS/QUIC setup.

The hint can be delivered in HTML using a link element placed early in the document head, or by the server as a Link response header, including via HTTP 103 Early Hints. Actual behaviour depends on the browser’s connection limits, current load, and network conditions, so benefits vary by context.

Preconnect establishes the network path to an origin before any HTTP request is made, covering the following steps of connection setup:

By initiating connection setup ahead of need, preconnect removes handshake latency from the critical path of the first request to that origin. The exact steps depend on the protocol (HTTP/2 over TLS versus HTTP/3 over QUIC) and whether caches or session resumption are available.

• DNS resolution: resolving the origin’s hostname to an IP address when not already cached.
• TCP handshake (for HTTP/1.1 and HTTP/2): establishing a TCP connection to the server’s IP and port, including SYN/ACK round trips.
• TLS handshake (for HTTPS over TCP): negotiating encryption and the application protocol (ALPN) with the server; session resumption may reduce the cost.
• QUIC/TLS handshake (for HTTP/3): setting up QUIC transport with integrated TLS; on resumption, 0-RTT or 1-RTT handshakes can further reduce latency.
• Connection pooling: preparing a reusable connection that can serve multiple requests to that origin (and, under some conditions, coalesced origins in HTTP/2/3).

What preconnect does for images: Preconnect resolves DNS and establishes the TCP and TLS/QUIC handshake to an origin before any image request is discovered. For images hosted on a different origin (CDN, subdomain, third-party), this removes 1–3 round trips from the critical path of the first image fetch.

When the primary image assets originate from a CDN or subdomain, the browser usually discovers the first image only after parsing HTML or CSS. Without preconnect, the first request to that origin waits for network setup, which can cost tens to hundreds of milliseconds per round trip on real mobile networks. Preconnect front-loads this work so bytes for the first image can flow as soon as it is discovered.

This is particularly relevant when the Largest Contentful Paint (LCP) element is an image served from a different origin. Eliminating DNS and handshake latency can modestly improve LCP, especially on high-latency or lossy links. Gains vary by route, protocol, and cache state; typical improvements range from tens of milliseconds on desktop broadband to several hundred milliseconds on congested mobile connections.

Scope and what to measure

Preconnect operates at the origin level and benefits only the first request(s) that would otherwise incur connection setup costs. Subsequent requests to the same origin reuse the warmed connection until it is closed or idles out. Its impact surfaces most clearly when the first critical resource to that origin is late-discovered and latency-bound, such as an LCP image on a third-party CDN.

Meaningful measurements include: the connectStart→connectEnd delta of the first request (via Resource Timing), time to first byte (TTFB) of the first cross-origin image, changes in LCP when the LCP image is remote, and overall page load milestones under mobile, high-latency conditions. Synthetic tooling (e.g., lab tests with consistent RTT/packet loss) and real-user monitoring can both reveal whether a preconnect is being reused and whether it shifts critical-path timing in practice.

Non-binding hint: Browsers treat preconnect (link rel=preconnect) as an advisory signal. Implementations may defer, throttle, or ignore it based on heuristics (e.g., current load, power state, metered networks). It is not a guarantee that a connection will be opened or reused.

Because it is a hint, preconnect competes with other page work and browser policies. Browsers cap the number of speculative connections, prioritise visible content, and may cancel idle warm-ups. On constrained devices or metered connections, they can ignore or delay preconnects to conserve power and bandwidth. A connection opened anonymously might not be reused for credentialed requests, prompting the user agent to create a second connection when the resource is fetched for real.

Practical outcomes differ by engine: some aggressively coalesce or prune preconnects; others keep them longer. The hint signals intent but does not force network activity, so measurement on target devices and networks is essential to understand its effect, and preconnects to non-critical origins should be avoided to prevent wasted sockets.

Related resource hints

DNS-prefetch

DNS-prefetch asks the browser only to resolve a hostname. It is lighter-weight than preconnect and can be suitable when connection setup cost is low or when over-connecting is a concern. Preconnect subsumes DNS-prefetch by performing DNS plus transport handshakes, so it is typically the more impactful option for latency-sensitive resources such as image CDNs.

Preload and prefetch

Preload fetches a specific resource with an explicit URL and priority, inserting it into the cache for later use. Prefetch retrieves a resource speculatively for a likely future navigation or phase of the page. Both inherently create the necessary connection, but they also transfer bytes and can contend for bandwidth. Preconnect is the more conservative choice when the URL is not yet known or when fetching the object itself would be premature.

Prerender/NoState Prefetch and Early Hints

Prerendering creates a whole-page speculative load and is much heavier than preconnect, while 103 Early Hints allows servers to send link relations (including preconnect) before the final response headers, advancing connection setup even earlier. For third-party image origins discovered late in HTML, Early Hints can provide the most headroom for beneficial preconnects.

Implementation notes

Rel=preconnect can be emitted as a link element in the document head or as a Link header from the origin or CDN. Placing it as early as possible increases the window for the browser to act. For cross-origin connections that will carry credentials (cookies, HTTP auth), adding the crossorigin attribute helps ensure the warm connection is reusable and avoids duplicative sockets when the real request is sent.

Limiting the number of preconnects to a small set of critical origins reduces the risk of over-connecting and wasting resources. Common candidates include the primary image CDN, font providers, and the analytics or tag vendor whose scripts gate rendering. If broad support is required, pairing preconnect with a dns-prefetch hint is a low-cost fallback for user agents that de-prioritise preconnect but still honour DNS-only hints.

The origin triple (scheme, host, port) must match how the images will be requested; preconnecting to https and then requesting via http, or to a different subdomain, yields no reuse. Under HTTP/2 and HTTP/3, some browsers can coalesce connections across origins when certificate SANs and IPs align, but this is not guaranteed and should not be relied upon for correctness. Servers and intermediaries may close idle sockets quickly, so late-discovered resources might not reap the full benefit if connection warm-up happens too early.

Comparisons

Preconnect vs DNS-prefetch

DNS-prefetch performs only name resolution, which is cheaper but yields smaller savings. Preconnect additionally sets up transport and security, offering larger gains for latency-sensitive first requests at the cost of opening sockets that may go unused if misapplied. For image-heavy sites with cross-origin CDNs, preconnect typically outperforms DNS-prefetch in LCP impact.

Preconnect vs Preload (images)

Preload fetches a specific image early and should be reserved for truly critical, above-the-fold assets with stable URLs and sizes. It consumes bandwidth immediately and can increase contention if overused. Preconnect avoids transferring bytes and is better when the critical image’s URL is not yet determined (e.g., responsive images selected by the browser) or when an entire origin’s first-byte latency is the bottleneck.

Preconnect vs Prefetch/Prerender (navigations)

Prefetch and prerender target likely future navigations and can drastically increase network and CPU usage. Preconnect is a lighter hint suited to improving the current page’s initial fetches to a known origin. Where bandwidth is limited or predictability is low, preconnect offers a safer balance of potential benefit versus risk.

FAQs

Does preconnect work with HTTP/3 and QUIC?

Yes. When the browser supports HTTP/3 to the target origin and has enough information to attempt QUIC (for example via Alt-Svc or prior knowledge), a preconnect can warm up the QUIC/TLS handshake. If HTTP/3 is not available, the browser typically warms an HTTPS (HTTP/2) connection instead. The protocol chosen is an implementation detail and may change as conditions evolve during the session.

Should the crossorigin attribute be included with preconnect for cross-origin images?

Including the crossorigin attribute on a cross-origin preconnect is advisable when subsequent requests will include credentials (cookies, HTTP authentication). Without it, the browser may open an anonymous warm connection that cannot be reused for credentialed requests, resulting in a second handshake when the image is actually requested. On same-origin preconnects, crossorigin has no effect.

How many origins should be targeted with preconnect on a typical page?

Most pages benefit from preconnecting to only a handful of truly critical origins—commonly the primary image CDN, the font provider, and one key script host. Over-connecting can consume socket slots, waste power on mobile devices, and even delay more important work. The right number depends on the page’s dependency graph and the device/network profile observed in real traffic.

Is preconnect still useful if DNS is already cached by the OS or browser?

Yes. DNS caching removes only one part of the latency. The TCP and TLS/QUIC handshakes still cost one or more round trips unless a reusable connection or session resumption is in place. Preconnect helps by performing those remaining steps early, and can be particularly beneficial when TLS negotiation or congestion on the first packets is the dominant delay.

Can preconnect ever harm performance or user experience?

Misapplied preconnects can occupy limited connection slots, keep idle sockets open, and waste power or data if the hinted origins are not used soon after. On highly concurrent pages, speculative connections may crowd out essential fetches. Keeping the target set small, favouring origins that gate critical rendering work, and validating impact with metrics reduces these risks.