Why Domain Sharding Hurts on HTTP/2

This guide is part of HTTP/2, HTTP/3 & Connection Management, within Network & Server Response Optimization. Domain sharding was a standard HTTP/1.1 technique: because browsers limited connections per hostname (typically six), sites split assets across static1.example.com, static2.example.com and so on to download more files in parallel. With HTTP/2 and HTTP/3, a single connection carries many concurrent requests, so sharding no longer adds parallelism. It only adds costs: a DNS lookup, TCP and TLS handshakes for each extra hostname, a new connection in slow start, and responses split across connections that the server cannot prioritise together.

Many sites still shard — through old CDN configurations, CMS plugins, or image services that rotate hostnames. Removing sharding is usually straightforward, but needs care with cached URLs, hard-coded references and cookies.

Rapid Diagnosis

• List asset hostnames in the Network panel (group by domain); multiple similar hostnames indicate sharding.
• Check connection timing: each shard shows its own DNS, connect and TLS segments.
• Check the protocol: sharding on HTTP/2 or HTTP/3 is almost always harmful.
• Check whether coalescing happens: if shards share an IP and certificate, Chrome may reuse one connection (shown by the same Connection ID column).

Root Cause Analysis

1. Legacy configuration. Sharding set up years ago for HTTP/1.1.

2. CMS or plugin defaults. Some image or asset plugins rotate hostnames automatically.

3. Cookie-free domains. Separate asset domains were also used to avoid sending cookies; HTTP/2 header compression makes cookie overhead much smaller.

4. Different certificates or IPs. Prevent coalescing, so each shard really costs a new connection.

Step-by-Step Resolution

1. Measure the cost

// Console: connection setup time per asset hostname.
const hosts = {};
for (const r of performance.getEntriesByType('resource')) {
  const h = new URL(r.name).host;
  const setup = r.connectEnd - r.domainLookupStart;
  if (setup > 0) hosts[h] = Math.max(hosts[h] || 0, Math.round(setup));
}
console.table(hosts);
// trade-off: reused or coalesced connections report 0 setup time, which is exactly
// what consolidation should achieve; cross-origin entries need Timing-Allow-Origin.

2. Consolidate onto one hostname

Serve all static assets from the main origin (through the CDN) or from a single asset hostname. Update templates, CSS and build configuration to emit the new URLs.

3. Redirect or keep old shard hostnames working

Keep old hostnames serving the same files (or redirecting) for cached HTML and external references, but stop generating new references to them.

4. If shards must remain, enable coalescing

When separate hostnames cannot be removed quickly, serve them from the same IP addresses with a certificate covering all names, so browsers can coalesce them onto one connection.

Verification

The Network panel should show assets coming from one hostname with a single connection (Connection ID column identical). Connection setup segments for asset requests should disappear after the first. In RUM, compare LCP and resource load delay for critical CSS and images before and after.

Worked Example: An Online Classifieds Site

A classifieds site served listing photos from img1 to img4.example-static.com, a scheme introduced in 2013. After moving to HTTP/2, each listing page opened five connections (main plus four shards), each with separate certificates. On mobile, listing pages spent about 900ms in connection setup before the first photo started downloading, and the LCP photo often waited behind thumbnails on other shards. Consolidating to static.example.com served via the same CDN as the main site, with one certificate covering both names, reduced connections to one (coalesced). LCP p75 improved by 520ms on mobile. Old shard hostnames kept serving files for six months for cached pages and external links.

Cookie-Free Domains Revisited

A secondary reason for separate asset domains was avoiding cookies on every asset request. HTTP/2's HPACK and HTTP/3's QPACK header compression mean repeated cookies on the same connection cost only a few bytes after the first request. The remaining reasons for a separate asset domain are organisational (separate infrastructure, security isolation for user uploads) rather than performance. For user-generated content, a separate domain is still a good security practice; serve it through the same CDN with coalescing where possible, or accept one extra connection.

Migrating Without Breaking Caches

Changing asset hostnames changes every asset URL, which invalidates browser and CDN caches for those files once. Plan the switch for a normal deploy (assets are re-downloaded at their new URLs) and avoid combining it with other large changes, so the one-off cost is easy to recognise in monitoring. Update the service worker's caching rules if it caches by hostname. Search the codebase, CMS content and email templates for hard-coded shard URLs; content editors often paste absolute image URLs that a template change will not catch.

Common Mistakes

• Consolidating without updating CSS references. Background images and fonts in CSS still point at old shards.
• Removing old hostnames abruptly. Cached HTML and external links break.
• Assuming coalescing works. Different IPs or certificates prevent it.
• Keeping sharding for "parallelism". HTTP/2 already multiplexes.

Edge Cases

HTTP/1.1 clients. A small share of clients and bots still use HTTP/1.1; they are not worth optimising for at the expense of everyone else.

Third-party CDNs for libraries. Public CDNs for libraries add a connection and no longer share cache across sites (cache partitioning); self-host instead.

Separate image CDNs. An image CDN on its own hostname is a legitimate extra origin; preconnect to it and keep it to one hostname.

Service workers. Sharded hostnames complicate service worker caching rules; consolidation simplifies them.

FAQ

Related

• Connection coalescing and certificates — when browsers share connections.
• DNS prefetch vs preconnect — warming the origins you keep.
• HTTP/2, HTTP/3 & connection management — the topic overview.