Web Performance & Standards
What is HTTP preconnect?
HTTP preconnect is a browser performance hint that instructs the browser to establish a network connection to a specified origin, completing the DNS resolution, TCP handshake, and TLS negotiation, before any resources from that origin have been explicitly requested. By completing these connection establishment steps early, during idle time or in parallel with other work, preconnect eliminates the connection setup overhead when the browser later needs to actually fetch resources from the preconnected origin.
Preconnect is implemented through a <link> element with rel="preconnect" in the HTML head, or through an HTTP Link response header, specifying the origin URL to preconnect to:
The key distinction between preconnect and resource-specific hints like preloading is that preconnect establishes the connection infrastructure, DNS, TCP, TLS, without fetching any specific resource. Preconnect is origin-level preparation, preparing the path to a server, while preload is resource-level preparation, fetching a specific file. Preconnect is appropriate when the browser knows it will need to connect to an origin but does not yet know which specific resources it will request from that origin.
For page speed and Core Web Vitals preconnect is most impactful for origins whose connection establishment time, DNS, TCP, TLS, adds measurable latency to resource loading. Third-party origins, CDNs, font services, analytics platforms, payment processors, are not connected to when the page begins loading, the browser discovers the need to connect only when it encounters a resource reference in HTML, CSS, or JavaScript. Preconnect eliminates the discovery-to-connection-establishment delay by preparing the connection before the resource reference is discovered.
What connection establishment involves
Understanding what preconnect eliminates, and why that matters for performance, requires understanding the steps involved in establishing a new HTTP connection to an origin.
DNS resolution, the first step in connecting to any new origin. The browser must resolve the origin’s domain name to an IP address through the DNS system. An uncached DNS lookup traverses the resolution hierarchy, from the local DNS resolver to root nameservers to TLD nameservers to the authoritative nameserver, accumulating latency at each step. DNS resolution for an uncached domain typically adds 20-150ms of latency, sometimes significantly more for slower DNS providers or complex DNS configurations.
For well-configured CDN infrastructure DNS resolution is typically fast, CDN DNS is heavily optimised and cached by major resolvers. For obscure third-party origins, small analytics vendors, niche payment processors, DNS resolution may be slower. Preconnect initiates DNS resolution early, the DNS query is in flight while the browser is still parsing HTML, so the resolution completes before it is needed.
TCP handshake, after DNS resolution the browser establishes a TCP connection through the three-way handshake, SYN, SYN-ACK, ACK, with the resolved IP address. The TCP handshake requires 1.5 round trips, approximately 1.5 × RTT latency. On a connection with 50ms round-trip time the TCP handshake adds approximately 75ms. On a mobile connection with 200ms RTT the TCP handshake adds approximately 300ms.
Preconnect completes the TCP handshake during idle time, the connection is established before the browser knows which specific resource to request from the origin. When the browser later discovers and requests a resource from the preconnected origin it reuses the already-established TCP connection, skipping the 75-300ms handshake delay.
TLS handshake, for HTTPS origins, which is essentially all modern origins, the TCP connection must be followed by a TLS handshake to establish encrypted communication. TLS 1.3 handshake requires 1 round trip, approximately 1 × RTT. On a 50ms RTT connection TLS 1.3 adds approximately 50ms. Combined with TCP the total connection establishment is approximately 125ms on a 50ms RTT connection, before any HTTP request can be sent.
Preconnect completes the TLS handshake during idle time, the full encrypted connection is ready before any resource request is made. Resource requests to preconnected HTTPS origins skip the full connection establishment, potentially saving 125-600ms depending on RTT.
Total connection establishment savings, on a typical broadband connection with 50ms RTT preconnect saves approximately 125ms per origin, the combined DNS, TCP, and TLS overhead. On a mobile connection with 200ms RTT preconnect saves approximately 550ms per origin. For a page loading resources from multiple third-party origins the cumulative savings can be significant, particularly on mobile connections.
Preconnect vs dns-prefetch
Preconnect and dns-prefetch are related hints that both prepare connections to future origins, but at different levels of completeness.
<link rel="preconnect">, establishes the complete connection, DNS resolution, TCP handshake, and TLS negotiation. Full connection establishment is more expensive in terms of CPU and battery usage, each preconnect consumes real network and processing resources. Preconnect connections are maintained for a limited time, typically 10 seconds in Chrome, before being closed if unused. Unused preconnects waste resources.
<link rel="dns-prefetch">, resolves only the DNS, finding the IP address without establishing a TCP or TLS connection. DNS prefetch is lower overhead, it consumes only the DNS lookup resources rather than full connection establishment. DNS prefetch is appropriate for origins that the browser will eventually connect to but not in the very near term, providing a head start on DNS without committing to a full connection.
Combining both hints, for browsers that support preconnect the preconnect hint handles everything including DNS. For browsers that support only dns-prefetch, older browsers, the dns-prefetch hint provides a fallback benefit. Using both hints provides cross-browser coverage:
When to use preconnect
Preconnect provides performance benefits only when connection establishment latency is a meaningful component of the critical resource loading path, and only for origins from which resources will definitely be loaded.
Critical third-party origins, origins that serve resources needed for above-the-fold rendering. Google Fonts is the canonical example, fonts loaded from fonts.googleapis.com and fonts.gstatic.com are often needed for text rendering. Connecting to these origins early ensures font requests are sent as soon as the font references are discovered in CSS:
CDN origins for critical assets, if a site serves CSS, JavaScript, or the LCP image from a CDN origin different from the page’s main origin preconnecting to the CDN origin ensures the connection is ready when the browser discovers those resources. This is particularly valuable when the CDN origin is discovered in CSS, after the browser has already downloaded and parsed the CSS file, rather than directly in the HTML.
Payment processor and checkout origins, for e-commerce sites the payment processor origin, Stripe, PayPal, Braintree, is needed when users proceed to checkout. Preconnecting to the payment processor origin on the cart or product pages, anticipating the checkout flow, can reduce checkout latency for users who proceed to payment.
Video and media streaming origins, for pages that load video content preconnecting to the video streaming origin reduces the connection establishment delay before video begins playing. Faster initial connection means shorter time to first frame.
When NOT to use preconnect
Indiscriminate preconnect application is counterproductive, preconnect for origins that are not used or not used in the near term wastes browser resources and can degrade performance.
Speculative origins that may not be used, preconnecting to an origin for a feature that only a small percentage of users trigger wastes connection establishment resources for the majority who do not trigger the feature. A live chat widget that only opens when users click a chat button does not warrant preconnect on every page load, dns-prefetch is more appropriate for low-probability connections.
Too many preconnect hints, every preconnect consumes real resources, CPU for TLS cryptography, memory for connection state, battery on mobile devices. Declaring dozens of preconnect hints, one for every third-party service ever used, consumes more resources than the connection savings justify. Limit preconnect to the 2-4 most critical third-party origins.
Origins with fast DNS and high cache hit rates, if DNS for an origin is consistently served from cache in under 5ms and the origin itself is frequently connected to, such that connections are often already established from a previous navigation, preconnect provides minimal benefit. Analytics the browser connects to on every page does not need preconnect, the connection is established on the first page and reused across navigations.
Same-origin resources, preconnect is for third-party origins, different domains from the page’s main origin. Resources from the same origin use the already-established connection to the main server, no preconnect is needed.
Preconnect implementation
HTML link elements in <head>, the standard preconnect implementation. Place preconnect hints as early in the <head> as possible, ideally as the first elements after the <meta charset> and <meta viewport> declarations, to maximise the time available for connection establishment:
HTTP Link response header, preconnect can be specified in an HTTP response header rather than in HTML, useful for server-side rendering scenarios where headers can be sent before HTML is streamed, or for adding preconnect hints to pages whose HTML cannot be modified:
HTTP headers are processed before HTML body parsing begins, preconnect specified in headers starts connection establishment at the earliest possible moment.
CDN and edge function injection, preconnect headers can be added to responses by CDN rules or edge functions, enabling preconnect hints for pages where neither HTML modification nor server configuration is feasible. A Cloudflare Worker or CDN response header rule can add Link preconnect headers to all page responses:
Preconnect and redirect management
For redirect management infrastructure preconnect has limited direct relevance, redirect responses themselves are small HTTP responses that do not load third-party resources. However preconnect is relevant for the destination pages reached through redirects.
Destination page performance, pages that receive significant traffic through redirects, brand protection domain redirects, campaign landing page redirects, domain migration redirects, benefit from preconnect implementation just like any other page. The redirect adds TTFB overhead before the destination page begins loading, optimising the destination page’s performance, including preconnect for critical third-party origins, partially offsets the redirect’s latency impact.
Preconnecting to redirect destinations, for redirect chains where the destination is known and consistent prefetching or preconnecting to the redirect destination from the page containing the redirect link can reduce the connection establishment overhead when the redirect fires. A page that links to old-domain.com, which redirects to new-domain.com, can preconnect to new-domain.com, preparing the connection before the user clicks:
Measuring preconnect impact
Chrome DevTools Network panel, the timing breakdown for any resource request shows how long was spent on DNS, Initial Connection, TCP handshake, and SSL, TLS handshake. Resources from preconnected origins show zero or near-zero time in these phases, the connection was already established. Comparing resource timing before and after adding preconnect hints quantifies the performance improvement.
WebPageTest, waterfall charts show connection timing for all resource requests. Resources that reuse preconnected connections show no DNS/connect/SSL phases in the waterfall, just the request and response phases. The time saved is visible as the difference in the connection establishment phases between preconnected and non-preconnected origins.
Lighthouse, the Use rel=preconnect to establish network connections early audit identifies origins that would benefit from preconnect hints, listing specific origins and estimating potential savings. This audit provides actionable recommendations for which origins to preconnect to.