Loading 180 tiled images with HTTP/2 vs. HTTP/1
http2.golang.org
Loading 180 tiled images with HTTP/2 vs. HTTP/1
1–10 of 57 posts
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#2I am shocked at the differences. A picture is worth a thousand words.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#3Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#4Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
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.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#5Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
Not sure, isn't the whole point of pipelining to avoid these domain-sharding workarounds?
This test case shows that the performance is better with the same code. The invert test case would show that the code is more complex (because of sharding) for the same performance (actually not quite, because of multiple handshakes).
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#6Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
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.
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!
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#7Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
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.
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.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#8Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
I wouldn't say so. Domain sharding is a hack, and not every website implements it, so I think this is a fair comparison.
Adding a third option with domain sharing might be reasonable, but I would expect that http2 still has the best performance.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#9Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
Yes and no. It would speed up the client receiving the images but at the detriment of flooding servers with connections (even moreso bad if HTTPS). I assume since this is on golang's site, this is also trying to show off the difference with just using the HTTP2 vs HTTP package.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#10Wouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
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.
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.