7 ms·
HTTP/2 technology demo
- shdon 11y agoHm, HTTP/1.1 at 15.5s, HTTP/2 at 23.72s Yeah, I "can see the difference clearly", but I don't think it is the kind of difference they expected or intended. Edit: Firefox 40 on Windows 7 at work. Will try at home as well. Oddly enough, the Akamai demo someone else posted gives me 18.47s for HTTP/1.1 and 2.24s for HTTP/2.
- Spone 11y agoHere: HTTP/1.1 at 15.48s and HTTP/2 at 2.06s
- Cshelton 11y agoMine was http/1.1 at 3.4~s and http/2 at 0.75s edit: this was Chrome 44.0.2403.155 m on windows 8 64
- kolme 11y agoWhat browser did you use? Are you sitting behind a proxy? For me: HTTP/1.1 at 13.19s, HTTP/2 at 1.48s
- deleted 11y ago[deleted]
- richym 11y agoShit happens :) I have HTTP/1.1 at 14.54s, HTTP/2 at 2.22s .. seems more like your configuration thing?
- shdon 11y agoMaybe. But the Akamai demo does show a major improvement for HTTP/2, so I think it is primarily a CDN77 thing. Maybe a bad route.
- JimmaDaRustla 11y ago1.91/0.48
- shdon 11y agoAt home (Firefox 40 on Windows 10) I get 2.34s for HTTP/1.1 and 1.26s for HTTP/2.
- linksbro 11y ago6.41s HTTP/1.1 vs 2.51s HTTP/2 on FF42. Very nice! (Although when HTTP2 is going the FPS drops quite a bit.) Can someone explain what exactly HTTP2 is doing differently to achieve such an improvement?
- kolme 11y agoUsing exactly one connection and multiplexing all the files into it (parallel downloads with only one socket).
- igl 11y agoVery simple: Instead of making 200 requests, http2 will use a single requests and stream in the chunks continuously. Also noticeable by the pictures not appearing randomly but in the same order they are sent out.
- ubernostrum 11y agoWell, they also appear to be stacking the deck a bit, by configuring HTTP/1.1 in ways that no sane person would (i.e., force-closing the connection after each resource -- HTTP/1.1 already supports re-using the existing connection for further requests, but they're explicitly disallowing that to make HTTP/2 seem better).
- Avalaxy 11y agoHTTP1 - 10.88s HTTP2 - 1.65s Chrome on Windows 8.1.
- cflat 11y agoThis is a copy of the Akamai's http2 demo: http://http2.akamai.com http://http2.akamai.com
- joeblau 11y agoMy results on the Akamai page have less of a difference between the results when compared to http://www.http2demo.io http://www.http2demo.io.
- takeda 11y agoAkamai's test does not cheat by sending Connection: close
- sajal83 11y agoAkamai's http/1 does keep alive. This one does not.
- mbq 11y agoAnd Akamai's is inspired by http://http2.golang.org/gophertiles http://http2.golang.org/gophertiles (which they acknowledge).
- nly 11y ago...and if you enable pipelining in Firefox, it's only 20% slower than HTTP/2 (~1.6s vs ~1.3s).
- patrickmcmanus 11y agobut pipelines have some real poorly performing cases (head of line blocking, cancel and retry semantics, etc..) that don't apply to h2 - those gotchas aren't represented in this test.
- nly 11y agoYup, it's true there are pathological cases. Problems with HOL blocking can be reduced significantly with good caching though. 50 blocking requests aren't much of an issue if they're all going to return small "304 Not Modified" responses straight out of the web servers file cache. And don't forget you can still get HOL blocking over HTTP/2... at the end of the day the browser has to start parsing HTML before it knows what else it needs to request. The only alternative is teaching your web server HTML or a set of heuristics and doing PUSH. And PUSH actually counter-acts the good in caching because when I load your index.html the web server has no idea whether I have jquery or your blogs stylesheet cached or not. What I really want when I visit a URL is for my browser to tell the web server when I last visited, and then for the web server to give me a complete list of all dependent resources and sub-resources that have changed since that visit.... basically a set of HEAD responses that constitute a diff. My browser can then just say "hmm, ok, I needed these last time, and they've changed, so while I'm downloading index.html I'll just go ahead and request this and this and this even though I have no idea how I'm going to load them yet". Basically, imho, all webpages should be cached as git repos ;)
- jpmonette 11y ago12.75s vs 1.40s. This is quite impressive - looking forward to a faster Web, slowly migrating to HTTP/2. Any clue if Amazon CDN service is / will offer HTTP/2 support too?
- JustSomeNobody 11y agoYou won't get a faster web, you'll just get more cruft shoved on each page.
- callum85 11y agoI don't think the limiting factor in "how much cruft should we add" is bandwidth. It's the point at which it becomes so hard to use that users leave. Example: Buzzfeed loads in 1 second for me on my work's broadband, but it's still full of junk making it hard to use. Bandwidth-wise, it could handle more crap on the page, but in terms of usability it's at the limit. I think you actually will get a faster and generally improved web when sites are finally able to end HTTP/1 support, because it will free up web developers from old performance hacks like asset concatenation, image sprites etc, which add a lot of friction to making websites. All that said, this demo is bullshit for the reasons given in other comments.
- joeblau 11y agoNot sure what is going on, but here were my results. HTTP1 - 3.13s HTTP2 - 0.54s
- dijit 11y agothe other server is 2x faster even without http/2 My wget implementation does not suppot http/2 HTTP Server: $ time wget https://1153288396.rsc.cdn77.org/http2/tiles_final/tile_18.png [...] real 1.038 user 0.038 sys 0.007 pcpu 5.37 HTTP2 Server: $ time wget https://1906714720.rsc.cdn77.org/http2/tiles_final/tile_18.png [...] real 0.539 user 0.045 sys 0.009 pcpu 10.01 of course that's just latency.. but this is hardly a scientific demonstration. We should also consider the fact that this is cherry picking the worst trait of HTTP/1.1 and that's that it's latency sensitive. A demo with a real webpage of large assets would be a better example.
- cotillion 11y agoSomething is very fishy. I tested this behind the evil-proxy-of-doom on the internal network and http2 was twice as fast despite the proxy barely supporting http1... But then real http2 against the http2 server is still 2.98 sec vs 8.65 sec.
- webXL 11y agoThey're closer to the same speed now. Some of the difference could be the I/O rate the h2 server has to contend with, right? The real way to demonstrate this would be to release a VM or container for people to test on their own server. And add a demo page of large assets, like you suggest.
- est 11y agoFunny, for me - HTTP/1.1 17.83s - HTTP/2 57.73s I guess I am living in a really remote area of the Interweb.
- youngtaff 11y agoIt is a real world demo though? Similar to many of the other demo's of HTTP/2 (Gopher Tile, Akamai) it's written in a way that presents HTTP/1.x in the worst light and manages to screw things up even more. HTTP/1.1 is really latency prone so when you have a demo that uses lots of smalls requests that don't fill up the congestion window you run into a couple of problems. 1. The browser can only use a limited number of connections to a host, so once these are in use the other requests queue behind waiting to a connection to become free. 2. Even when one becomes free, we've got the request / response latency before the browser sees an images bytes 3. If the response doesn't fill the congestion window i.e. it's a small file, then there's spare capacity that's not being used i.e. packets we could have send it the round trip that didn't. 4. In this demo the server sends connection: close so forces the browser to open a new TCP connection and negotiate TLS for each of the tiles, so the congestion window won't grow either. Yes, HTTP/2 is faster, because it can send multiple requests at the same time to overcome latency, the server can fill the congestion window, and the window will grow. But are our web pages build of tiny image tiles, or a greater variety of image and resources sizes? EDIT: They've now enabled keep-alive which makes the HTTP/1.1 test much faster than it was
- GGoood 11y agoIts demo you retard. They want you to see the difference between HTTP/1.1 and HTTP/2, so it makes sense to send connection: close.
- takeda 11y agoRegarding #4 isn't this a bit cheating, who doesn't use keep-alive. Also what about request pipelining? Doesn't that basically do the sane thing what http/2 is doing?
- sajal83 11y agoyes #4 is totally cheating. But pipeling is very different from http/2 multiplexing. pipeling the responses has to come in order they were requested.. so it could suffer from head of line blocking. http/2 is async in that regards.
- 11y ago
- Cshelton 11y agoRecently the .net 4.6 has allowed windows server to run some http/2 for the edge browser, it greatly improved the load speed and web socket calls of our app.
- sajal83 11y agoThe test is a lie. While I don't doubt improvements in http/2, this test uses "Connection: close" on the http/1.1 test, which means for each tile there needs to be a tcp connect and TLS handshake. This is not representative of real world. In http/2 the "Connection: close" header is meaningless and all the tiles come from the same connection.
- zamalek 11y agoPlaying the devil's advocate; "Connection: close" merely exaggerates the underlying issue. That being said, the comparison would have definitely been fairer with keep-alive and having to resort to a trick like this makes me wonder how much faith they have in their own product.
- bhouston 11y agoCheaper and faster than AWS Cloudfront with free custom SSL. So what is the catch? One issue is our data is on S3 and I believe that any outgoing S3 traffic to this CDN would be slow and cost money, but S3 to CloudFront is is likely prioritized and free.
- sajal83 11y agoOutgoing traffic from S3 has no bandwidth cost associated with it.
- k__ 11y ago12.50 -> 1.41 Chome 44, Win 7 With this, JS bundling is a thing of the past, I think.
- breatheoften 11y agoIgnoring the technical issues with the demo that have been pointed out -- how does this actually prevent the need for a js bundle building process of some kind? Suppose page.html depends synchronously on A.js depends synchronously on B.js depends synchronously on C.js. Somehow page.html needs to statically represent that it depends on each of A,B,C to avoid requiring a roundtrip after each new dependency is loaded. Yes the roundtrip cost is lower, but minimizing the number of roundtrips is desirable even over http2. The utility of a module bundler like webpack which walks the dependency graph of A.js and constructs a static representation of all the dependencies required by the html page seems like its somethings thats still going to be desirable to use even with http2 ...
- AhtiK 11y agoThis demo could be possibly even faster if using HTTP/2.0 Server Push. Btw, note that if you're looking into supporting HTTP/2.0 on your own then with nginx there's still some waiting left: https://www.nginx.com/blog/early-alpha-patch-http2/ https://www.nginx.com/blog/early-alpha-patch-http2/ And there's no plan to support server push with the first production release. So NGINX users will have to keep using SPDY. AFAIK the latest plan with SPDY is to remove it from Chrome browser in early 2016 so nginx has to make sure to deliver before that...
- pornel 11y agoThis test only demonstrates that CDN77 can't serve HTTP/1.1 properly.
- JustSomeNobody 11y agoAwesome! Now web sites can pack 6 times more ads and other cruft onto each page.
- noitisnt 11y agono connection: close anymore
- tatar007 11y agoyes u'r right man!
- kefs 11y agoHere's a fun overview video explanation of HTTP/2 from the other day.. https://www.youtube.com/watch?v=yc2Ug2GySCg https://www.youtube.com/watch?v=yc2Ug2GySCg
- mtgx 11y agoNow make those images webp.
- sajal83 11y agoIt appears they turned on keep alive in http/1.1 test now. http/1.1 timings improved by a lot ... still obviously slower than http/2
- sulami 11y agoRan this a couple of times in Firefox 40/Linux x86_64, HTTP/1.1 was always faster by 10-20% (~1s vs. ~1.15s).
- halosghost 11y agoIn my case (and I'm not sure why), HTTP/1.1 consistently got ~5s and HTTP/2 consistently got ~10s. I assume I was supposed to see the opposite result? :P
- sulami 11y agoReading the comments here, the results seem to fluctuate heavily in dimensions, winners and margins. I guess, this test is just not an epitome of anything at all.
- pluma 11y agoChrome 43 on Linux from Germany here. HTTP/2 routinely outperforms HTTP/1.1 by several seconds for me. HTTP/1.1 being somewhat stable at 7-8 seconds and HTTP varying from 4 to 11 seconds (though generally closer to 11 seconds than to 4). The Akamai demo works fine: https://http2.akamai.com/demo https://http2.akamai.com/demo (though HTTP/2 is only ahead by 20% or so)
- pg_is_a_butt 11y agothe 14MB HTTP/1 demo ran significantly faster than the HTTP/2 demo... re-ran many times with same result.
- TwistedWeasel 11y agoMy results show 1.3s for HTTP/1.1 and 3.0 seconds for HTTP/2 using Chrome on OS X. So, this demo wasn't very impressive for me.
- hmage 11y agoThat means your internet is fast enough to reduce latency problem that HTTP/2 fixes. on mobile the difference is much bigger, like, 100s vs 5s
- lojack 11y agoSame for me. I tried numerous times and couldn't get HTTP/2 to be faster than HTTP/1.1. I had one time where it was close, but the vast majority of the time its between 2x and 4x slower than HTTP/1.1.
- aberatiu 11y agoDid anyone else observer the JS in the iframe footer? I'm just curios why it's obfuscated and what's its purpose (see surce of https://1153288396.rsc.cdn77.org/http2/http1.html https://1153288396.rsc.cdn77.org/http2/http1.html)
- throw7 11y agoHow about a demo that doesn't require javascript to be enabled to work? Or is javascript a hard requirement for HTTP/2?
- rickjr1985 11y agothis HTTP 2.0 was faster for me by only .01 seconds.
- manigandham 11y agoThe speed test links at the bottom for single files don't make any sense. A single file download wouldn't benefit from the upgraded protocol and just seems, from very rough testing on my 100mb line, like the http/1 links are artificially slowed down.
- spullara 11y agoIt is interesting that Safari & Firefox beat Chrome in the HTTP/1.1 test for me. However, the HTTP2 test is then twice as fast as Safari. Maybe we can stop smashing all those javascript files together.
- gbachik 11y agoLol ran slower than http1 on my iPhone :/
- apdapreturns 11y agoPerfect. http://puu.sh/jIiG4/731c98e894.jpg http://puu.sh/jIiG4/731c98e894.jpg
- callum85 11y agoWhat browser?
- patrickmcmanus 11y agoThe test server does not actually make sure the h2 test is using h2. If you are using a client that does not have h2 support then you are just using the fallback code on the server and testing h1 against h1. An iphone is a good example :) (but it may be using spdy instead.. lots of variables)
- saurik 11y agoIgnoring HTTP/2, I'm finding it very interesting that on my 11" MacBookAir6,1 running OS X 10.9.5, Safari 7.0.6 is much faster than Chrome 44.0.2403.155 at the HTTP/1.1 test. Safari performs the test in almost exactly 3.00 seconds, while Chrome never comes in under 3.15 and often takes as high as 3.45.
- darkhorn 11y agoHow can I enable HTTP/2 on Apache?
- igrigorik 11y agoSee http://httpd.apache.org/docs/trunk/mod/mod_h2.html http://httpd.apache.org/docs/trunk/mod/mod_h2.html
- myth_buster 11y agoFor me (on FF) HTTP/1.1 was faster in around 5/7 attempts. I'm on corporate network so not sure that's affecting it.
- kgc 11y agoHTTP/2 is consistently slower for me...
- jamesladd 11y agoI ran the demo several times and I got a 1 second difference. I guess there is a place where even 1 second is important.