Domain Sharding vs. Connection Coalescing

[Kirby]

Not 100% accurate. Read about HTTP/2 & HTTP/3 Connection Coalescing https://blog.cloudflare.com/connection-coalescing-experiments/

Example of it in action on my Wordpress blog at https://blog.centminmod.com/ for HTTP/2 dependency chart and connection waterfall where 3 of my subdomains serving assets are utilising connection coalescing

I am aware of Connection Coalescing

This was one of the reasons why I wrote that domain sharding should be done carefully.

The blog post you linked doesn't contradict my statement, in fact if stresses my point:

• Performance
  Additional TLS handshakes and TCP connections can incur significant costs in terms of cpu, memory and other resources.
  Thus, coalescing requests to use the same connection can optimize resource utilization.
• Resource Prioritization
  Multiplexing requests on a single connection means that applications have better visibility and more direct control over how related resources are prioritized and scheduled. In the absence of coalescing, the network properties (for example, route congestion) can interfere with the intended order of delivery for resources. This reliability gained through connection coalescing opens up new optimization opportunities to improve web page load times, among other things.

The idea behind domain sharding is to increase the amount of connections to work around head-of-line blocking and maximize throughput.
Connection coalescing pretty much does the opposite, it tries to minimize the amount of connections to reduce per connection overhead (TLS handshake, etc.).

If connection coalescing is being used for domains www.forum.com, js.forum.com and data.forum.com (which is like @Mr. Jinx has setup his installation) there will be no additional connections for js.forum.com and data.forum.com.

From TCP/IP-Stack point of view, all requests will go through just one connection, so this doesn't increase nor decrease the amount of connections.

It also doesn't help much in terms of better privacy - it is already known that content from forum.com is being requested; in fact it could leak more metadata if connection coalescing is not used in such a setup:
Think of a subdomain adultcontent.forum.com - this would leak (via SNI) that adult content is being requested (which would not be the case if everything is requested through just forum.com).

What do you gain by splitting forum.com static content to a subdomain?
This subdomain could be cookie-free which does save a bit of traffic for requests - on the other hand this does add one additinal DNS query to resolve the subdomain.
Adding further subdomains (in case of connection coalescing) does require furhter DNS queries without gaining anything else.

If connection coalescing is not being used, two additional DNS queries and TLS handshakes would be required for a setup like Mr. Jinx - this would most likely slow things down.

Your use of connection coalescing is different:
You do not use it to shard your domain to increase connections but to "map" 3rd party content (like the webvitals-polyfill JS from unpkg.com via unpkg.centminmod.com and Google Tag Manager JS via gtag.centminmod.com).
This is most certainly beneficial, but it is not domain sharding.

I therefore still stand by my statement:
Domain sharding was primarily a HTTP/1 technology to work around head-of-line blocking and should be used with care for HTTP/2+

 

[eva2000]

What do you gain by splitting forum.com static content to a subdomain?

From an HTTP prioritization point of view, it can be another way of manipulating when and what order assets are loaded on your page depending on what you are sharding though.

If connection coalescing is not being used, two additional DNS queries and TLS handshakes would be required for a setup like Mr. Jinx - this would most likely slow things down.

If you're using Cloudflare for HTTP/2 or HTTP/3 for all apex and sub domains, then you're effectively using connection coalescing anyway

Your use of connection coalescing is different:
You do not use it to shard your domain to increase connections but to "map" 3rd party content (like the webvitals-polyfill JS from unpkg.com via unpkg.centminmod.com and Google Tag Manager JS via gtag.centminmod.com).
This is most certainly beneficial, but it is not domain sharding.

Yeah, my usage case is different, but the point was to illustrate under what circumstances domain sharding would still work over HTTP/2 and HTTP/3 HTTPS situations.

 

[Kirby]

From an HTTP prioritization point of view, it can be another way of manipulating when and what order assets are loaded on your page depending on what you are sharding though.

Yeah, theoretically this could be the case.
But has anyone ever made tests that revealed real gains in production?
At least I am not aware of any such findings.

If you're using Cloudflare for HTTP/2 or HTTP/3 for all apex and sub domains, then you're effectively using connection coalescing anyway

Not everybody does use CloudFlare
In fact it could soon become legally pretty problematic to use CloudFlare in Germany due to a missing replacement for privacy shield & GDPR.

Yeah, my usage case is different, but the point was to illustrate under what circumstances domain sharding would still work over HTTP/2 and HTTP/3 HTTPS situations.

Your usecase isn't domain sharding, that's the point.

MDN definition of domain sharding:

Browsers limit the number of active connections for each domain. To enable concurrent downloads of assets exceeding that limit, domain sharding splits content across multiple subdomains.

Your usecase does not fit this definition; you don't hit a limit for those two single resources requested from 3rd party domains (every connection would request just one resource) and your mapped domains don't help to overcome this (no-existing) limit.

 

[eva2000]

But has anyone ever made tests that revealed real gains in production?

I've been using custom HTTP/2 prioritization of assets for over 15+ months now for my forums and Wordpress blog with some gains on my already optimized page loads. But for most folks they may not see as much i.e. like reducing LCP for a Wordpress page from 600-900ms (0.6s to 0.9s) to 350-550ms (0.35s to 0.55s).