The Case for Reusing One Connection Across Multiple Hostnames

Modern web pages load dozens of subresources — scripts, stylesheets, images, beacons — and each hostname involved can trigger a separate DNS lookup, TCP connection, and TLS handshake. Those extra round trips add latency, and each new TLS connection exposes metadata, including plaintext DNS queries or unencrypted SNI. One way to reduce both problems is connection coalescing: reusing an existing connection to fetch resources from a different hostname that happens to resolve to the same server.

Connection reuse is not a new idea. HTTP/1.1 allowed persistent connections, but requests on a single connection had to be serialized, so browsers opened multiple parallel TCP connections to the same origin to get concurrency. It was not until HTTP/2 that multiplexing on one connection became standard. A less-publicized property of HTTP/2 — also present in HTTP/3 — is the ability to reuse a connection across different hostnames, provided certain conditions are met.

Coalescing offers three practical benefits:

  • Privacy: A coalesced request exposes only one destination via SNI instead of several, making it harder for on-path observers to fingerprint user activity.
  • Performance: Fewer TLS handshakes and TCP connections mean less cryptographic work and lower memory/CPU overhead on both client and server.
  • Prioritization: Multiplexing all subresources on a single connection lets the application control request scheduling more directly, without network-level interference from separate connections on different routes.

There are reasons to be cautious. TCP congestion control divides bandwidth fairly among connections, so a client that opens many connections may get a larger total share on a congested path. Browsers also schedule requests differently across one connection versus many, and load balancing can suffer because requests on a single connection all need to be handled by the same TLS-termination process. These risks call for empirical testing before broad deployment.

Testing Coalescing at Scale

To measure real-world feasibility, we ran a controlled experiment using cdnjs, a popular CDN-hosted JavaScript/CSS library used by a large share of websites. We identified about four thousand Cloudflare Free plan sites likely to load cdnjs resources, split them evenly into a control and an experiment group, and enabled coalescing only for the experiment group. That meant serving the sites and cdnjs from the same IP addresses in several regions, with TLS certificates covering both hostnames — the two conditions HTTP/2 requires for coalescing.

WebPageTest measurements from private instances showed the effect clearly. In the experiment group, roughly half of the requests to cdnjs were coalesced, meaning the requests rode on an existing connection to the parent site. Chrome created about 78% fewer TLS connections to cdnjs for experiment sites; Firefox reduced connections by only about 22%, even though it also coalesced requests — Firefox appears to open connections it doesn't end up using.

Not every site coalesced. Some loaded cdnjs resources with the crossorigin="anonymous" attribute (needed for CORS-based subresource integrity checks), and browsers did not reuse connections for those requests. The same held for subresources fetched via XMLHttpRequest or the Fetch API. There was no evidence that coalescing hurt performance: page load time and Largest Contentful Paint differences between the experiment and control groups were not statistically significant.

What the Results Suggest

Coalescing is feasible in production and delivers measurable privacy and efficiency gains — over 50% of real-world cdnjs requests were coalesced in the experiment group, with no downside for user experience. The technique deserves wider exploration, particularly around more aggressive reuse policies, comparing IP-based coalescing with approaches like Origin Frames, and pushing browser vendors to adopt the more flexible coalescing rules in HTTP/3. For now, the data suggests the main obstacles are browser policy choices rather than fundamental protocol limitations.