from here, with 1sec delay, 3 attempts, avg values, empty cache each time.. 38.7s vs 58.3s
Loading 180 tiled images with HTTP/2 vs. HTTP/1
21–30 of 57 posts
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#22I wonder how well will a reverse http/2-proxy, in front of a http/1-server will behave
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#23Earlier quoted context omitted.
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 fo…
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.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#24Note 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 personally still think that JS should still always be pre-processed.
When you can spend longer up front optimizing the concatenation, minification, and compression, you can amortize that additional cost across every request and still make important incremental gains.
A bit saved is a bit earned.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#25I wonder how well will a reverse http/2-proxy, in front of a http/1-server will behave
It could be rather complex, but almost certainly will still help. It could, for example, heuristically process the script tags as HTML passes back through it to the client, make optimistic requests to the HTTP/1 server (presumably at a much lower latency than the client), then push those documents down to the client.
And of course, it could also cache that knowledge and do it all instantly.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#26It seems to be offline now?
It's not offline. There's just a long latency...
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#27Akami http2 demo https://http2.akamai.com/demo
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#28Note 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.
Similarly to GZIP applied by the Web Server, you could build your minification in, although given that the approaches are more varied and less standard it might not be the greatest idea.
It sounds like you're describing PageSpeed: https://developers.google.com/speed/pagespeed/module
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#29The reverse schadenfreude here is great. All the haters on HN complained about HTTP/2 endlessly, and here we've given them a faster Internet anyway.
Re: Loading 180 tiled images with HTTP/2 vs. HTTP/1
#30Note 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 personally still think that JS should still always be pre-processed. When you can spend longer up front optimizing the concatenation, minification, and compression, you can amortize that additional cost across every request and still make important incremental gains. A bit saved is a bit earned.
You can and should still compress and do some amount of minification. Concatenation is debatable on sites with varied page types and JS needs.
> A bit saved is a bit earned.
So don't send bits the user probably won't need? :P