Connection Coalescing and Certificates

This guide is part of HTTP/2, HTTP/3 & Connection Management, within Network & Server Response Optimization. Every distinct hostname normally needs its own connection, with its own DNS lookup, handshakes and slow start. HTTP/2 and HTTP/3 allow an exception: if a browser already has a connection to a server, and a new hostname resolves to an IP address of that connection, and the server's certificate is valid for the new hostname, the browser may send requests for the new hostname over the existing connection. This is connection coalescing.

Coalescing turns separate hostnames — www.example.com, static.example.com, img.example.com — into one connection, saving hundreds of milliseconds on mobile. It happens automatically when conditions are right, and silently fails when they are not: a certificate missing a name, a different IP set from the CDN, or an anonymous versus credentialed connection pool mismatch.

Rapid Diagnosis

• Enable the Connection ID column in the Network panel: requests to different hostnames with the same ID were coalesced.
• Check certificate SANs: openssl s_client -connect www.example.com:443 -servername www.example.com | openssl x509 -noout -text | grep DNS:.
• Compare DNS answers for the hostnames: overlapping IPs are required for Chromium coalescing.
• Check crossorigin usage: fonts and CORS requests use anonymous connections, separate from credentialed ones.

Root Cause Analysis

1. Certificates without all names. Each hostname has its own certificate.

2. Different IPs. CDNs may return different anycast IPs or pools for different hostnames.

3. Connection pool split. Anonymous (crossorigin) requests cannot use credentialed connections and vice versa.

4. Different CDNs or providers. Hostnames served by different infrastructure cannot coalesce.

Step-by-Step Resolution

1. Use a certificate that covers all hostnames

Issue a certificate with all relevant hostnames in the Subject Alternative Name list, or a wildcard (*.example.com) that covers subdomains. Serve the same certificate for all of them.

2. Serve hostnames from the same IPs

Point all hostnames at the same CDN configuration (or the same anycast IPs). Check with dig +short that answers overlap.

for h in www.example.com static.example.com img.example.com; do echo "$h: $(dig +short $h | tr '\n' ' ')"; done
# trade-off: CDNs may rotate IPs per query; overlap needs to exist for the
# browser's cached answers, so using the same CDN property is most reliable.

3. Align credentials modes

Fonts and other crossorigin requests use anonymous connections. If the page loads fonts from static.example.com with crossorigin and images without, the browser may need two connections. Preconnect with and without crossorigin only where both are needed.

4. Verify in the browser

Reload with the Connection ID column visible; requests to the coalesced hostnames should share the main document's connection ID.

Verification

The Network panel should show one connection ID for the main document and coalesced asset hostnames. Connection setup timing for asset requests should be zero. Resource Timing for coalesced hosts shows connectStart === connectEnd. In RUM, compare resource load delay for critical assets before and after.

Worked Example: A University Website

A university site loaded pages from www, CSS and JS from assets, images from media, and fonts from fonts — four hostnames, each with its own certificate, though all ran on the same CDN. Pages opened five connections (including an anonymous one for fonts). The team issued one certificate covering all four names and moved them into one CDN property so DNS answers matched. Chrome then coalesced assets and media onto the main connection, and fonts used one anonymous connection. Connections before LCP fell from five to two, and LCP p75 on mobile improved by 280ms.

Coalescing vs Consolidation

Coalescing is a safety net, not a design goal. Consolidating everything onto one hostname is simpler and works in every browser and pool. Coalescing helps when separate hostnames must exist — for organisational reasons, legacy URLs, or security isolation — and makes them nearly free. Browsers implement coalescing slightly differently (Chromium requires IP overlap; Firefox can also use HTTP/2 ORIGIN frames, where servers declare the origins they serve), so do not depend on it for critical paths if you can consolidate instead.

Auditing Coalescing Across a Site

Coalescing can break silently when a certificate is renewed without one of the names, or when a subdomain moves to a different CDN property. Add a periodic check that resolves each hostname used on key pages, compares the IP sets, and inspects the certificate served for each to confirm it lists all the names. In the browser, a synthetic test can count distinct connection IDs on page load (via the Chrome DevTools Protocol) and alert if the number rises. Treat the number of connections before LCP as a tracked metric, like bundle size, so changes to infrastructure show up in the same dashboards as code changes.

Common Mistakes

• Assuming a wildcard certificate is enough. IPs must overlap too.
• Mixing CDNs for subdomains. Different infrastructure prevents coalescing.
• Overusing crossorigin. Splits requests into the anonymous pool unnecessarily.
• Huge SAN lists. Very large certificates add bytes to every handshake.

Edge Cases

Third-party domains. You cannot coalesce with origins you do not control.

Misdirected requests. If a server receives a coalesced request for a hostname it does not serve, it should respond with 421 Misdirected Request, and the browser retries on a new connection.

Privacy considerations. Some browsers limit coalescing in specific privacy modes.

HTTP/3. Coalescing applies to HTTP/3 as well, under the same certificate rules.

FAQ

Related

• Why domain sharding hurts on HTTP/2 — consolidating hostnames.
• DNS prefetch vs preconnect — preconnect and connection pools.
• Eliminating redirect chains — other connection costs before TTFB.