8 ms·
Loading 180 tiled images with HTTP/2 vs. HTTP/1
- ben_pr 12y agoI am shocked at the differences. A picture is worth a thousand words.
- dsiegel2275 12y agoWouldn't a more fair comparison involve domain sharding for the HTTP/1 impl?
- mohamedattahri 12y agoGood 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 agoAgreed. 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 agoCertainly, 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 agoI 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 agoBoth 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 agodomain 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.
- LaurentVB 12y agoNot 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).
- Kudos 12y agoThe whole point of pipelining is to avoid expensive TCP operations. Domain-sharding is effectively a workaround for the workaround (limiting connections to hosts). 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.
- nfriedly 12y agoI 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.
- invisible 12y agoYes 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.
- mohamedattahri 12y agoThe page is also a reference server implementation for people working on clients are well.
- zserge 12y agoDoes anyone know when the HTTP/2 client for Go will be available? And, are they likely to include http/2 into a standard net/http package?
- hayksaakian 12y agoA Better idea for a demo: Take the top 20 website on the web, and get their static assets from archive.org Show me how much faster they load. I'm imagining sites like CNN or Yahoo which serve many images on their home page could load faster. How much faster?
- geoffreyvdb 12y agoIt seems to be offline now?
- daddykotex 12y agoSame for me
- mholt 12y agoSeems to be having trouble with the all TLS handshakes from HN. Plaintext http connection works for me (but it's not http/2)
- elchief 12y agoIt's not offline. There's just a long latency...
- jewel 12y agoNote 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.
- nickspacek 12y agoSimilarly 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.
- cbr 12y agoIt sounds like you're describing PageSpeed: https://developers.google.com/speed/pagespeed/module https://developers.google.com/speed/pagespeed/module
- Kudos 12y agoThis is one of the more exciting parts for me. 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.
- 12y ago
- mahouse 12y agoThe server seems to be overloaded right now. Anyway, disable HTTPS Everywhere if you have it, since if you don't do it there will be no difference. :-)
- _lce0 12y agofrom here, with 1sec delay, 3 attempts, avg values, empty cache each time.. 38.7s vs 58.3s
- _lce0 12y agoI wonder how well will a reverse http/2-proxy, in front of a http/1-server will behave
- andrewstuart2 12y agoIt 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.
- floatboth 12y agonghttpx, the proxy from the nghttp2 package, turns rel=preload links from the Link header into server push: https://nghttp2.org/documentation/nghttpx.1.html#server-push https://nghttp2.org/documentation/nghttpx.1.html#server-push
- codewithcheese 12y agoAkami http2 demo https://http2.akamai.com/demo https://http2.akamai.com/demo
- bsdetector 12y agoFirefox Nightly: HTTPS 1.1: 22 ms latency, 2.83s load time HTTPS 2: 17 ms latency, 2.91s load time Network panel in web developer tools says the second was actually fetched over HTTP/2 so it looks like the demo worked... just not as intended. So HTTP/2 provides no performance benefit in this case. Although I do have pipelining turned on, and unlike the gopher tiles demo this server actually returns "Connection: Keep-Alive" header necessary for pipelining to be used so that might explain it; Microsoft Research did determine that SPDY and pipelining have essentially the same page load performance.
- mankyd 12y agoYeah, HTTP/2 smoked HTTP/1.1 for me: HTTP/1.1: Latency: 57ms. Image load time: 7.69s HTTP/2: Latency: 30ms. Image load time: 0.97s
- iotku 12y agoChromium: HTTPS 1.1: 140ms latency, 46.47s load time HTTPS 2: 25ms latency, 4.76s load time Definitely a difference on a high latency (Sat) connection, although I'm not aware what the latency amount is based on.
- bsdetector 12y agoAnd now you know why Google never tested against pipelining... if they had they'd have to sell it as marginally faster and more sensible, rather than saying it is up to 10x faster. Since you are on satellite I suggest trying Firefox and turning on aggressive pipelining in about:config. As far as I know I've never had a problem with it in years, and as you can see it brings HTTP/2 speeds to non-SSL and older sites.
- 12y ago
- dcsommer 12y agoThe 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.
- einrealist 12y agoInteresting. If the tiles are cached by the browser, HTTP/2 is slower than version 1. Only for the first request HTTP/2 was tremendously faster than its predecessor.
- iotku 12y agoRan this a while ago on my Satellite connection [1], it's really exciting for users with high latency. Satellite internet services have come a long way from what it used to be and has a much higher raw speed than before, but of course you can only do so much with latency when the signal is traveling such a distance. [1]: https://www.youtube.com/watch?v=Ut-8ieRg1yE https://www.youtube.com/watch?v=Ut-8ieRg1yE
- motoboi 12y agoCould someone please explain what is going on in this demo?
- pfranz 12y agoI'm guessing the submitter saw this talk at PyCon that used the page as illustration: Cory Benfield - Hyperactive: HTTP/2 and Python https://youtu.be/ACXVyvm5eTc https://youtu.be/ACXVyvm5eTc It's a new major version of HTTP. At the high level it's backwards compatible (status codes, urls, etc are the same), but the communication of those things changed. It's binary instead of plain text (a major point of contention), it's stateful instead of stateless (it can refer back to previous requests, which makes debugging harder when you jump in the middle of a communication), it can multiplex data (send multiple files concurrently--this is where the demo shines), adds a prioritization layer, and header compression. I may have some of those details wrong--all of that I learned from the talk.
- ZeroGravitas 12y agoThe Google Page speed service has a test page where you provide a URL and it runs it through the webpagetest.org service twice, to show before and after times (and other details) for all the various optimisation techniques it applies automatically. https://developers.google.com/speed/pagespeed/service/tryit https://developers.google.com/speed/pagespeed/service/tryit One of these optimisations is the use of SPDY/HTTP2 I believe? (Actually seems like WebPageTest has some issues with HTTP2 currently, though it's at the top of their TODO list to fix them: https://github.com/WPO-Foundation/webpagetest/issues/20 https://github.com/WPO-Foundation/webpagetest/issues/20) It would be great if they (or someone else) provided this service but only changed the use of HTTP2 so that people could run this benchmark on their own sites, and people could get a comprehensive view on what kinds of sites would benefit from switching today (without even bothering to remove old optimisations like image spriting etc.) Those sites that benefit without any change may be the first to move, as so many workflows are built around concatenation of files etc. and that workflow will still be needed for some percentage of users, probably for years to come, so an initial, easy win would be good to demonsrate. I'm hopeful that if you use SSL then HTTP/2 will always be faster, but it would be good to see some data on that.