Wouldn'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.
Loading 180 tiled images with HTTP/2 vs. HTTP/1
11–20 of 57 posts
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#12Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#13There are still some gains from combining the files, as it will mean less headers will go over the wire, and you'd still want to minify them so that there were less total bits, but the gains aren't going to be as big as they used to be.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#14Note that this means that there's no longer a pressing need to consolidate multiple javascript files into one file, likewise with CSS files. Icon sprites aren't necessary either. There are still some gains from combining the files, as it will mean less headers will go over the wire, and you'd still want to minify them so that there were less total bits, but the gains aren't going to be as big as they used to be.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#15It seems to be offline now?
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#16Wouldn'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).
You can actually do both domain-sharding and still use only a single TCP connection. SPDY/HTTP2 will reuse existing connections if they receive the same cert/ip combo. It's the best of both worlds while http1 still has some marketshare.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#17Anyway, disable HTTPS Everywhere if you have it, since if you don't do it there will be no difference. :-)
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#18Note that this means that there's no longer a pressing need to consolidate multiple javascript files into one file, likewise with CSS files. Icon sprites aren't necessary either. There are still some gains from combining the files, as it will mean less headers will go over the wire, and you'd still want to minify them so that there were less total bits, but the gains aren't going to be as big as they used to be.
At Udemy ~90% of our visitors have SPDY3 or better (tech-savvy audience). Our JS needs an overhaul and the timing is great for a rethink on how we deliver it.
We're looking at optimising for those users and no longer bundling our JS and CSS. We need to test it further because we can't simply flick a switch and flick it back if it doesn't work out, we'll need to move away from Fastly to somewhere that has SPDY first.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#19It seems to be offline now?
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#20Note that this means that there's no longer a pressing need to consolidate multiple javascript files into one file, likewise with CSS files. Icon sprites aren't necessary either. There are still some gains from combining the files, as it will mean less headers will go over the wire, and you'd still want to minify them so that there were less total bits, but the gains aren't going to be as big as they used to be.
I'm curious as to how javascript engines perform with one hundred files multiplexed VS one giant file.