4 ms·

Good point, but domain sharding is just a clever optimization (hack) to emulate some of the parallelism provided by HTTP/2 out of the box.

jtruk 12y ago
Agreed. For 'the regular web' (outside those organisations that have the nous and resources to optimise) this is a really clear demo. Roll on HTTP2!
lomnakkus 12y ago
Certainly, but comparing X-as-almost-never-practiced[1] to Y is pretty disingenuous unless you're going to very clearly state up front that that is what you're doing. Of course, the hackiness of X-as-practiced is a valid point of qualitative comparison and should indeed be brought up. [1] Ok, I'm exaggerating a little. It's not quite "never", but most large sites where image loading time is an issue are using some form of workaround, be it spriting, multiple domains, or something else.
- kbenson 12y ago
  I think the point is that these sites get an efficient solution for free rather than spending time and resources on designing and implementing sharding. Just because it's common for sites with loading time constraints doesn't mean they wouldn't have been a whole lot happier to not have to have dealt with it.
mohamedattahri 12y ago
Both your points are valid if the comparaison is strictly based on performance gains. The problem is they imply that optimizing is free and easy.
patrickmcmanus 12y ago
domain sharding gives you parallelism - but it totally bypasses congestion control. At certain levels this works in your favor - because congestion control tends to be overly conservative for HTTP - but at levels of sharding too high it is a disaster (packet loss, heavy buffering, reordering and huge delays to sort it all out.) Unfortunately the appropriate level of sharding isn't something the person doing the markup can know - because its based on the runtime path characteristics of each page viewer. Much better to multiplex in one congestion control context (like http/2 does) and then work on making congestion control work better (like the various blah over udp projects such as quic are trying to do). Plus if you do this you can add prioritization, which is a big deal.

jtruk 12y ago

Agreed. For 'the regular web' (outside those organisations that have the nous and resources to optimise) this is a really clear demo. Roll on HTTP2!

lomnakkus 12y ago

Certainly, but comparing X-as-almost-never-practiced[1] to Y is pretty disingenuous unless you're going to very clearly state up front that that is what you're doing. Of course, the hackiness of X-as-practiced is a valid point of qualitative comparison and should indeed be brought up. [1] Ok, I'm exaggerating a little. It's not quite "never", but most large sites where image loading time is an issue are using some form of workaround, be it spriting, multiple domains, or something else.

kbenson 12y ago
I think the point is that these sites get an efficient solution for free rather than spending time and resources on designing and implementing sharding. Just because it's common for sites with loading time constraints doesn't mean they wouldn't have been a whole lot happier to not have to have dealt with it.

mohamedattahri 12y ago

Both your points are valid if the comparaison is strictly based on performance gains. The problem is they imply that optimizing is free and easy.

patrickmcmanus 12y ago

domain sharding gives you parallelism - but it totally bypasses congestion control. At certain levels this works in your favor - because congestion control tends to be overly conservative for HTTP - but at levels of sharding too high it is a disaster (packet loss, heavy buffering, reordering and huge delays to sort it all out.) Unfortunately the appropriate level of sharding isn't something the person doing the markup can know - because its based on the runtime path characteristics of each page viewer. Much better to multiplex in one congestion control context (like http/2 does) and then work on making congestion control work better (like the various blah over udp projects such as quic are trying to do). Plus if you do this you can add prioritization, which is a big deal.