HTTP/2, HTTP/3 & Connection Management: Fewer, Faster, Better-Shared Connections

This topic is part of Network & Server Response Optimization. Every resource a page loads travels over a connection, and connections are expensive to create: a DNS lookup, a TCP handshake, a TLS handshake, and a period of slow start while the congestion window grows. On a mobile network with a 150ms round-trip time, creating a new HTTPS connection over TCP takes 300–450ms before the first request can even be sent. How many connections a page needs, and how well they are used, has a large effect on loading speed.

HTTP/1.1 allowed only one request at a time per connection, so browsers opened up to six connections per host, and developers invented workarounds: domain sharding (spreading assets across hostnames to get more connections), sprites and concatenation (fewer requests), inlining. HTTP/2 multiplexes many concurrent requests over one connection, with header compression and stream prioritisation, which makes most of those workarounds unnecessary and some harmful. HTTP/3 runs HTTP over QUIC, a UDP-based transport with built-in TLS 1.3: it needs fewer round trips to set up, avoids TCP's head-of-line blocking when packets are lost, and survives network changes such as moving from Wi-Fi to cellular.

Protocol upgrades are mostly configuration at the CDN or server. The bigger, ongoing work is connection management: limiting the number of distinct origins on the critical path, making sure connections are reused and coalesced, warming necessary connections early, and verifying in the field which protocols users actually get.

The Metric Degradation This Topic Addresses

Connection costs appear in TTFB (for the document's own connection), in resource load delay for critical subresources on other origins (fonts, CSS on a CDN domain, the LCP image on an image CDN), and in overall load time when many third-party origins are involved. In Navigation and Resource Timing, they show as domainLookup, connect and secureConnection durations; in waterfalls, as the coloured DNS/connect/TLS segments before a request starts.

Packet loss is the other factor. On TCP, a lost packet stalls every HTTP/2 stream on that connection until it is retransmitted (transport head-of-line blocking). On lossy mobile networks this can make HTTP/2 slower than several HTTP/1.1 connections. HTTP/3 avoids this because QUIC streams are independent.

Prerequisites

• RUM data with nextHopProtocol and connection timing per resource (or at least for the navigation).
• A list of origins contacted during page load, with which are on the critical path.
• CDN and server configuration access to enable TLS 1.3 and HTTP/3.

1. Environment Setup: Inventory Origins and Protocols

// Console: origins used during load, protocol, and connection time.
const byOrigin = {};
for (const r of performance.getEntriesByType('resource')) {
  const o = new URL(r.name).origin;
  const e = (byOrigin[o] ||= { count: 0, protocol: r.nextHopProtocol, connectMs: 0 });
  e.count++;
  e.connectMs = Math.max(e.connectMs, Math.round(r.connectEnd - r.domainLookupStart));
}
console.table(byOrigin);
// trade-off: cross-origin timing details are zero without Timing-Allow-Origin;
// the protocol is still reported for most resources.

2. Capture a Baseline

Record the number of origins on the critical path (before LCP), connection times for each, the share of navigations and resources over h3 versus h2, and TTFB and LCP by protocol in the field.

3. Isolate Unnecessary Connections

Classify each origin: needed early (critical CSS, fonts, LCP image), needed later (analytics, chat), or avoidable (sharded asset domains, a separate domain for a single small file). Check whether multiple hostnames could share a connection via coalescing.

4. Apply: Consolidate, Upgrade, Warm

Consolidate critical resources onto the main origin or one CDN hostname. Enable TLS 1.3 and HTTP/3. Remove domain sharding. Preconnect to the few remaining critical third-party origins. Defer non-critical third parties until after load.

<!-- Warm the one critical third-party origin; self-host the rest. -->
<link rel="preconnect" href="https://images.example-cdn.com" crossorigin>
<!-- trade-off: each preconnect opens a socket and does TLS work even if the
     origin is not used soon; limit preconnects to two or three critical origins. -->

Deconstructing HTTP/2 and HTTP/3 Behaviour

Multiplexing. HTTP/2 and HTTP/3 send many requests concurrently over one connection, interleaving response frames. This removes the HTTP/1.1 per-connection request queue, so many small files are no longer expensive — although each request still has some overhead, and very large numbers of tiny files remain less efficient than moderately bundled ones.

Prioritisation. With many requests on one connection, the server decides which responses to send first. Browsers signal priorities (render-blocking CSS and the LCP image high, async scripts and lazy images low), and the fetchpriority attribute adjusts them. HTTP/2's original dependency-tree priority scheme was implemented inconsistently by servers; the newer Extensible Priorities scheme (Priority header, urgency and incremental flags) is used by HTTP/3 and modern HTTP/2 implementations. Poor server prioritisation can delay critical resources behind large, unimportant ones.

Connection reuse and coalescing. Browsers reuse an open connection for further requests to the same origin. They can also coalesce: if a new hostname resolves to the same IP as an existing connection and the certificate covers both names, the browser can send requests for both over one connection. This makes separate asset subdomains nearly free — if configured correctly.

HTTP/3 discovery. Browsers learn that a server supports HTTP/3 from the Alt-Svc response header (or from DNS HTTPS records). The first visit typically uses HTTP/2; subsequent connections may use HTTP/3. DNS HTTPS records allow HTTP/3 on the first connection.

Advanced Diagnostics and Edge Cases

UDP blocked. Some corporate networks block UDP 443; browsers fall back to HTTP/2. Expect a share of users to never use HTTP/3.

Connection limits and slow start. A single new connection starts with a small congestion window; large early responses take several round trips to ramp up. Reusing warm connections avoids slow start.

Credentialed vs anonymous connections. Browsers keep separate connection pools for requests with and without credentials. Fonts and crossorigin resources use anonymous connections, so preconnect needs crossorigin to warm the right pool.

Third-party origins. Each adds DNS, connection and TLS cost, plus prioritisation that your server cannot control. Self-hosting critical third-party resources (fonts, key scripts) often helps more than any protocol setting.

Server push. HTTP/2 server push has been removed from browsers. Use 103 Early Hints with preload instead.

Validation and Budgeting

Validate protocol adoption with nextHopProtocol in RUM: the share of navigations over h3 should rise after enabling HTTP/3, typically to a majority for repeat visitors on mobile. Compare TTFB and LCP by protocol and by connection type. Budget the number of origins contacted before LCP.

Worked Example: A Travel Booking Site

A travel site's homepage contacted 14 origins before LCP: the main site, a static asset domain, an image CDN, three font origins, a tag manager, an A/B testing service and several ad-tech domains. Connection setup for critical origins added 400–700ms on mobile. The team served static assets and fonts from the main origin (via the CDN), kept the image CDN with a preconnect, deferred the tag manager and A/B script until after LCP (moving experiments to the edge), and enabled HTTP/3 and TLS 1.3 at the CDN. Origins before LCP fell to three, h3 share reached 64% of navigations, and LCP p75 on mobile improved from 3.3 seconds to 2.4 seconds. The protocol upgrade alone accounted for about 120ms; consolidating origins for most of the rest.

Measuring Protocol Gains Honestly

HTTP/3 improvements are real but uneven. Users on fast, stable connections see little difference; users on high-latency or lossy networks see the most. Averaged across all users, gains can look small and be mistaken for noise. Segment field data by protocol and by network quality (effective connection type, round-trip time from Network Information API where available, or country) to see where gains concentrate. Be careful with selection bias: users who get HTTP/3 are disproportionately repeat visitors with a known Alt-Svc, who also have warmer caches. Comparing before and after enabling HTTP/3 for the same population is more reliable than comparing h2 and h3 users in the same period.

Legacy HTTP/1.1 Optimizations to Undo

Several techniques from the HTTP/1.1 era are counterproductive now. Domain sharding adds connections that must each be set up and that compete for bandwidth without coordinated prioritisation. Excessive concatenation into one giant bundle defeats caching (any change invalidates everything) and delays execution until the whole file arrives. Image sprites force downloading every icon to show one. Inlining large assets as data URIs bloats HTML and CSS and prevents separate caching. Each made sense when requests were expensive; with multiplexing, a moderate number of well-cached files usually performs better.

Early Hints and Connection Warmup

When the server needs time to generate the HTML, it can send a 103 Early Hints response immediately with Link headers for critical resources (rel=preload for CSS, fonts and the LCP image, rel=preconnect for critical origins). The browser starts connecting and downloading during the server's think time. Early Hints work over HTTP/2 and HTTP/3 and are supported by major CDNs, which can cache and replay hints for each URL. They are the modern replacement for server push, with the advantage that the browser decides whether it needs each resource.

Third-Party Origins and the Critical Path

Most of the connections a typical page opens are to third parties: analytics, tag managers, consent platforms, A/B testing, chat, ads, social embeds, font services. Each is a separate origin with its own connection setup, and none can be coalesced with yours. When any of them sits on the critical path — a synchronous script in the head, a font stylesheet, an anti-flicker snippet — its connection cost adds directly to FCP and LCP.

Audit third parties by when they are needed. Fonts and critical CSS should be self-hosted so they share the main connection. Experimentation and personalisation can often move to the edge or server, removing the client-side script from the critical path. Analytics, chat and marketing tags can load after the page is interactive. For the few third-party origins that must load early, a preconnect hint starts the connection in parallel with the HTML. The goal is a critical path that touches one or two origins, with everything else arriving later on connections that do not delay rendering.

A Rollout Plan

1. Inventory origins and protocols on key templates.
2. Enable TLS 1.3 and HTTP/3 at the CDN; add HTTPS DNS records if supported.
3. Remove domain sharding and consolidate critical assets onto one origin.
4. Self-host critical third-party resources such as fonts.
5. Preconnect only to remaining critical origins; defer non-critical third parties.
6. Add Early Hints for pages with significant server think time.
7. Track nextHopProtocol, origins before LCP, and LCP by protocol in RUM.

Common Pitfalls

• Domain sharding on HTTP/2. More connections, worse prioritisation.
• Too many preconnects. Wasted sockets and CPU, and contention with critical work.
• Missing crossorigin on preconnect for fonts. Warms the wrong connection pool.
• Assuming HTTP/3 for everyone. UDP blocking and first visits still use HTTP/2.
• Relying on server push. Removed from browsers; use Early Hints.

FAQ

Guides in This Topic

• Measuring real-world HTTP/3 gains — field measurement by protocol.
• Why domain sharding hurts on HTTP/2 — undoing a legacy optimization.
• Connection coalescing and certificates — sharing connections across hostnames.
• Diagnosing head-of-line blocking — when one stream stalls the rest.

Related

• DNS prefetch vs preconnect — warming connections.
• Time to First Byte (TTFB) optimization — connection time in TTFB.
• Using fetchpriority to prioritize the LCP image — prioritisation over multiplexed connections.