Modern web pages load resources from dozens of domains: CDNs, analytics providers, advertising networks, and subdomains for static assets. Each new connection traditionally requires a TCP handshake, TLS negotiation, and slow-start ramp-up, adding hundreds of milliseconds per origin. Connection coalescing addresses this by reusing a single HTTP/2 or HTTP/3 connection for multiple domains when certain conditions align.

How Connection Coalescing Works

When a browser establishes a connection to cdn.example.com, it inspects the TLS certificate’s Subject Alternative Names (SANs) field. If the certificate covers cdn.example.com, static.example.com, and assets.example.com, and all three domains resolve to the same IP address, the browser can multiplex requests for all three origins over the same connection.

The browser validates two criteria: certificate authority and IP address matching. The TLS certificate must explicitly list each domain, and DNS resolution must confirm they point to the same server. This prevents security violations where an attacker with control over one subdomain could intercept traffic for another.

HTTP/2 and HTTP/3 make this practical through stream multiplexing. A single connection carries multiple concurrent requests, each tagged with a stream identifier. The :authority pseudo-header in each request frame indicates the target origin, allowing the server to route requests correctly despite arriving over a shared connection.

The CDN Use Case

CDNs are the primary beneficiaries of connection coalescing. A typical setup might serve:

• www.example.com for HTML
• static.example.com for JavaScript and CSS
• img.example.com for images
• fonts.example.com for web fonts

Without coalescing, the browser opens four separate connections, each incurring setup overhead. With a wildcard or multi-SAN certificate and consistent DNS configuration, all four origins share one connection. The initial page load sees significant latency reduction, especially on high-RTT mobile networks where each handshake is expensive.

CloudFlare, Fastly, and Akamai all support connection coalescing in their edge configurations. The technique is particularly effective when combined with HTTP/2 Server Push or Early Hints, where the server can proactively send assets for multiple origins before the browser explicitly requests them.

DNS and Certificate Requirements

Connection coalescing requires tight coordination between DNS and TLS configuration. All participating domains must resolve to the same IP address at connection time. This typically means A and AAAA records pointing to the same edge node.

The TLS certificate must be configured with all relevant domains in the SAN field. Wildcard certificates like *.example.com work for subdomains, but cross-domain coalescing (like example.com and example.net) requires explicit listing. Certificate authorities typically charge more for certificates covering many distinct domains, but the performance gain often justifies the cost.

Some CDN configurations use CNAME flattening or ALIAS records to ensure consistent IP resolution while maintaining flexibility in backend routing. This adds complexity but enables coalescing even when origin servers change frequently.

Security and Privacy Considerations

Connection coalescing introduces subtle security implications. If a user visits public.example.com and internal.example.com, and both coalesce over the same connection, timing side channels could leak information about internal resource access patterns to the public site’s JavaScript.

Browsers mitigate this by restricting coalescing to same-origin or explicitly trusted cross-origin scenarios. Firefox and Chrome both implement strict checks that prevent coalescing when the origins have different security contexts, such as mixed content policies or CORS configurations.

From a privacy perspective, coalescing can reduce fingerprinting surface area. Fewer open connections means less observable network behavior. However, it also concentrates traffic patterns, making it easier for network observers to correlate activity across multiple subdomains.

Performance Impact and Limitations

The benefit of connection coalescing scales with the number of domains and the latency of the network path. On a low-latency wired connection, saving 20-30ms per connection might be imperceptible. On a 4G mobile connection with 100ms RTT, eliminating three or four connection setups can reduce page load time by half a second or more.

Connection coalescing does not eliminate the need for connection management. Browsers still limit the total number of concurrent streams per connection (typically 100-250 for HTTP/2), and head-of-line blocking can occur when a slow response delays subsequent requests on the same stream. HTTP/3’s QUIC transport addresses some of these issues with improved loss recovery, but coalescing still carries tradeoffs.

The technique is transparent to most web applications. No code changes are required; the optimization happens entirely at the transport layer. The main operational challenge is coordinating DNS and certificate management to meet the coalescing requirements, particularly in large organizations with distributed infrastructure teams.