How to Reduce Website Load Time with Multiple CDN Subdomains

Short answer: For most sites using HTTP/2 or HTTP/3, adding multiple CDN subdomains is not a dependable way to reduce load time. HTTP/2 can multiplex many asset requests over one connection, so the old reason for splitting requests across hostnames largely disappears. Extra hostnames can add DNS lookups and connection setup. Start with a shared asset origin, effective CDN caching, and measurements from your actual visitors; keep sharding only if a controlled comparison shows a repeatable benefit.

A CDN can still make a site faster by caching eligible assets at edge locations closer to visitors. That benefit comes from cache behavior and placement, not from multiplying hostnames. This guide explains how to decide, configure an experiment, interpret results, and troubleshoot the common failure modes.

1. What CDN subdomain sharding does

Domain sharding means distributing assets across multiple hostnames, such as static-a.example.com and static-b.example.com, instead of one asset hostname. Under older HTTP/1.1 browser behavior, per-domain connection constraints could limit parallel downloads. More hostnames could allow more connections and concurrent downloads.

With HTTP/2, requests can be multiplexed over a single connection. The U.S. Web Design System’s HTTP/2 Performance Guide says, “Do not use the domain splitting technique.” Cloudflare also describes the costs of extra DNS, TCP, and potentially TLS handshakes, and notes that separate connections limit prioritization across domains. HTTP/3 is another modern transport to evaluate where the CDN and browser support it; Google Cloud recommends enabling it where supported, but that is not a guarantee of improvement for every site.

In practice, an additional hostname may require DNS resolution and a separate transport connection. If it is cross-origin, the browser may need TCP and TLS setup too. Those steps can cost more than the concurrency gained, especially for pages with many small resources.

2. Separate hostname from CDN benefit

A hostname does not automatically put content on a CDN. The hostname must route through the CDN, the response must be eligible for caching, and the cache must actually serve a hit for the request. Cloudflare documents that DNS-only records are not proxied and cached by its service, and its CDN troubleshooting guidance calls out subdomains outside the CDN path as a reason expected caching does not happen.

Before creating more asset subdomains, confirm these basics:

The asset hostname resolves to the intended CDN or is otherwise configured to use the CDN.
TLS certificates cover every hostname, and HTTPS requests do not redirect through an unnecessary chain.
Cache rules allow the asset types and URL patterns you expect to cache.
Response headers, cookies, query strings, and authorization do not unintentionally bypass caching.
The browser or CDN reports cache hits for representative assets.

Edge caching can reduce the distance to the origin and avoid repeated origin trips. Cloudflare describes edge and tiered caching; Google Cloud’s CDN guidance also discusses request coalescing, which can limit duplicate concurrent cache fills to an origin. These are independent levers from sharding.

3. Decide whether sharding is worth testing

Record the baseline. Pick representative pages, locations, devices, and network conditions. Capture page-level outcomes such as Largest Contentful Paint and total load time alongside the browser’s network waterfall.
Check negotiated protocols. Inspect the protocol shown for actual asset requests (for example, h2 or h3). Do not infer it from CDN settings alone.
Check cache behavior. Identify cache hits, misses, revalidations, origin fetches, and assets excluded from caching. Fix routing or cache eligibility problems before evaluating hostname count.
Make one controlled variant. Keep asset contents, cache policy, compression, and page code the same. Change only the hostname distribution so the result answers the sharding question.
Repeat across the audience that matters. Run enough repeated samples to account for variable DNS, network, cache warmness, and geography. Compare medians and the spread, not one unusually fast run.
Keep the simpler arrangement unless the gain repeats. Include operational cost: DNS records, TLS coverage, cache rules, CSP and CORS configuration, monitoring, and future asset deployments.

Track at least: DNS lookup time per host, connection and TLS setup time, request queueing and transfer timing, cache status, page-level load metrics, and error rates. Compare cold and warm cache runs separately. A variant that improves one waterfall but worsens the audience’s page-level experience is not a useful win.

There is a narrow, measured exception in the literature: an Akamai 2017 paper, “Domain-Sharding for Faster HTTP/2 in Lossy Cellular Networks”, reports a 12% median page-load-time improvement in good network conditions for its tested HTTP/2 sharding setup. This is specific to that experiment, not a general expected result. The paper’s reported discussion also cautions that pages with hundreds of small objects can lose the gain when multiple TCP/TLS setups add latency. Use it as a reason to test a relevant workload, not as a promise.

4. Practical configuration options

Keep one asset hostname by default

Serve cacheable static assets from one well-configured CDN hostname. Use long-lived caching for versioned or fingerprinted files, and ensure the CDN’s cache key and origin headers match the intended reuse. Keep HTML and user-specific responses on appropriate policies rather than applying a broad static-asset rule to everything.

Use multiple hostnames for operational reasons when useful

Separate hostnames can still help with ownership boundaries, migration, distinct cache policies, or serving assets from different origins. Treat that as an architecture choice. Do not assume the split itself speeds delivery. For every hostname, maintain DNS, valid TLS, cache routing, and any necessary CSP or CORS allowances.

Evaluate HTTP/3 and CDN features

Where supported by your CDN and audience, test HTTP/3 as a protocol option. Also review CDN edge and tiered caching, compression, cache revalidation, and request coalescing. Enable one change at a time and measure it with the same methodology. Protocol availability does not guarantee that every request uses that protocol or that every workload improves.

Account for browser and origin behavior

Cross-origin asset hosts can affect CORS for fonts and other restricted resources. A Content Security Policy must allow each required host. Cookies scoped too broadly can be sent to asset subdomains and may prevent shared caching or add request bytes. Use the narrowest cookie scope consistent with the application. If assets vary by user or authorization, do not make them publicly cacheable merely to increase hit rate.

5. Common errors and fixes

Symptom	Likely cause	Fix
New subdomain has no faster responses	It resolves directly to the origin or bypasses the CDN.	Verify DNS/proxy routing and inspect response/cache status at the edge.
First visit is slower after sharding	Each hostname adds DNS and connection setup, while HTTP/2 already multiplexes requests.	Compare the single-host baseline and remove the split unless representative tests show a repeated improvement.
Assets keep showing cache misses	Cache rules exclude the path or query, response headers prohibit caching, cookies are present, or the cache key varies unnecessarily.	Inspect the CDN cache status and origin headers; adjust policy only for content safe to share.
Certificate warning or failed HTTPS request	The certificate does not include the new hostname, or DNS points to the wrong endpoint.	Issue/attach a certificate covering the hostname and verify DNS and TLS from the public path.
Font or script blocked by the browser	CORS or Content Security Policy does not allow the new origin.	Update the narrow CORS response and CSP directives for the exact asset host; inspect the browser console.
Assets load but page metrics get worse	More parallel connections compete for bandwidth or stream prioritization is fragmented across origins.	Use page-level metrics and waterfall timing; consolidate requests and retest.
Results vary from run to run	Cache warmth, geographic routing, DNS cache state, or network variability differs.	Repeat paired runs, separate cold and warm results, and test representative user locations and connections.

6. Performance, reliability, and cost notes

Sharding is not free even if the DNS records themselves cost little. It adds configuration and failure surfaces: hostname resolution, certificate renewal and coverage, cache policy consistency, CORS/CSP updates, and monitoring. An outage or misconfiguration on one shard can break only part of a page, which may be harder to diagnose than a single asset origin.

CDN cost depends on the provider’s current pricing, traffic, cache hit ratio, request count, and origin egress; this dossier does not establish comparable prices, so check your provider’s current terms. Improving cacheability can reduce origin traffic, but a hostname split alone does not guarantee lower spend and can increase request or connection overhead. Measure both visitor experience and CDN/origin usage before keeping a change.

7. Inspect pages and capture reproducible evidence

When comparing the baseline and variant, use the same URL, viewport, browser conditions, and cache state so screenshots and page details are comparable. ScreenshotNeo is a website screenshot API and MCP server for developers; it can capture a page with one GET request and provides page information tools for AI agents. It is useful for producing consistent visual records alongside your browser performance measurements, though a screenshot is not a substitute for network timing data.

For local browser-based measurement, use your browser’s developer tools: open the Network panel, preserve the log, reload under a documented cache condition, and export a HAR for each variant. Record the tested location and whether HTTP/2 or HTTP/3 was negotiated on the asset requests. Compare multiple runs rather than relying on a single capture.

Or skip the browser setup

One request returns a screenshot; see the ScreenshotNeo API documentation for options. Example using the target site:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`ScreenshotNeo returned ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

ScreenshotNeo accepts cookie and consent banners before capture and removes 60+ known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, and failed loads are never billed, and responses identify page verdict and billing status. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 screenshots. Learn more at ScreenshotNeo, then sign up free.

FAQ

Should I create multiple CDN subdomains for a new site?

Usually no. Start with one asset hostname and validate CDN caching and protocol negotiation first.

Does a CDN automatically make every asset fast?

No. The asset must pass through the CDN and be cacheable under the configured rules; cache misses still involve the origin.

Can HTTP/1.1 still benefit from sharding?

Possibly, depending on browser limits, request patterns, connection reuse, and network conditions. Measure the actual audience and deployment before retaining it.

Is HTTP/3 a guaranteed replacement for sharding?

No. It is a protocol option to evaluate where supported. Confirm which protocol real requests negotiate and compare page-level outcomes.

How many CDN subdomains should I use?

There is no universal optimal count. Use the fewest that meet your operational needs unless measurement supports a different design.