
HTTP/2 technology demo - LeZuse
http://www.http2demo.io/
======
youngtaff
It 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

~~~
takeda
Regarding #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?

~~~
youngtaff
From memory request pipelining is disabled in most browsers as many
intermediaries (proxies etc) screw it up, it's still vulnerable to head-of-
line blocking even when it's enabled.

You'd be surprised how many servers don't have keep-alive enabled, it's much
more common than I'd like.

I'm a great fan of HTTP/2 but I'd like to see realistic tests!

~~~
bsdetector
There has been one realistic test that I know of, done by Microsoft Research,
and they found pipelining to be basically equivalent to HTTP/2.

But that doesn't fit the narrative. Did Google ever test against pipelining?
Did IETF? No, they didn't. Did Google ever show the effect of head-of-line
blocking on page load speed, especially when spread over several independent
TCP connections? No, they didn't. Why didn't they do this basic research
before pushing their new protocol?

They just said "it's 40% faster! rubber stamp this because it's in Chrome!"
and some of their fans even created stacked demos where pipelining wouldn't be
used (perhaps unintentionally, but still invalid comparisons).

~~~
youngtaff
Is it this paper -
[http://research.microsoft.com/pubs/170059/A%20comparison%20o...](http://research.microsoft.com/pubs/170059/A%20comparison%20of%20SPDY%20and%20HTTP%20performance.pdf)

I think if you read back though people like Will Chan's and others blogs it
becomes clear that pipelining doesn't work reliably enough outside a test lab
environment plus HoL blocking is still an issue for it

~~~
bsdetector
"Doesn't work reliably enough" doesn't answer the question of why Google
didn't test HTTP/2 against pipelining. None of Google's performance
improvement claims compared to pipelining, and they've never demonstrated or
quantified an actual real-world head of line blocking problem (ironically,
other than Google Maps loading very slowly in HTTP/2 because of a priority
inversion).

Will Chan is the guy that wrote "it’s unclear what these intermediaries are".
Oh well, there's some bad software out there, let's just make a whole new
protocol /s. Fix the bad software, or at least find out what it is. If it's
malware causing the problems, you don't need to make a whole new protocol you
can just get rid of the malware.

------
sajal83
The 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
Playing 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.

~~~
sajal83
concurrency is not impacted by this, but its affects window scaling, and 2 - 4
extra round trips _per request_ for the connection setup.

~~~
zamalek
> concurrency is not impacted by this

You're right. Watched it closely a second time and there's definitely
concurrency.

------
dijit
the 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.

~~~
webXL
They'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.

------
cflat
This is a copy of the Akamai's http2 demo:
[http://http2.akamai.com](http://http2.akamai.com)

~~~
joeblau
My 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
Akamai's test does not cheat by sending Connection: close

------
pornel
This test only demonstrates that CDN77 can't serve HTTP/1.1 properly.

------
AhtiK
This 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...

------
sulami
Ran 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
In 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
Reading 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
Chrome 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)

------
sajal83
It 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

------
linksbro
6.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?

~~~
igl
Very 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.

------
jpmonette
12.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
You won't get a faster web, you'll just get more cruft shoved on each page.

~~~
callum85
I 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.

------
Cshelton
Recently 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.

------
TwistedWeasel
My 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.

~~~
lojack
Same 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.

------
saurik
Ignoring 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.

------
aberatiu
Did 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))

------
shdon
Hm, 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.

~~~
richym
Shit happens :) I have HTTP/1.1 at 14.54s, HTTP/2 at 2.22s .. seems more like
your configuration thing?

~~~
shdon
Maybe. 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.

------
patrickmcmanus
The 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)

------
manigandham
The 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.

------
bhouston
Cheaper 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
Outgoing traffic from S3 has no bandwidth cost associated with it.

~~~
james33
That isn't true. S3 has no bandwidth cost for incoming traffic, but it
certainly does outgoing to the internet:
[https://aws.amazon.com/s3/pricing/](https://aws.amazon.com/s3/pricing/).

~~~
sajal83
Oops my bad. Havent had my full dose of coffee today.

------
spullara
It 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.

------
kefs
Here'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)

------
apdapreturns
Perfect.
[http://puu.sh/jIiG4/731c98e894.jpg](http://puu.sh/jIiG4/731c98e894.jpg)

~~~
callum85
What browser?

------
myth_buster
For 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.

------
noitisnt
no connection: close anymore

~~~
tatar007
yes u'r right man!

------
throw7
How about a demo that doesn't require javascript to be enabled to work? Or is
javascript a hard requirement for HTTP/2?

------
jamesladd
I ran the demo several times and I got a 1 second difference. I guess there is
a place where even 1 second is important.

------
JustSomeNobody
Awesome! Now web sites can pack 6 times more ads and other cruft onto each
page.

------
k__
12.50 -> 1.41

Chome 44, Win 7

With this, JS bundling is a thing of the past, I think.

~~~
breatheoften
Ignoring 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
...

------
gbachik
Lol ran slower than http1 on my iPhone :/

------
kgc
HTTP/2 is consistently slower for me...

------
joeblau
Not sure what is going on, but here were my results.

HTTP1 - 3.13s

HTTP2 - 0.54s

------
Avalaxy
HTTP1 - 10.88s

HTTP2 - 1.65s

Chrome on Windows 8.1.

------
darkhorn
How can I enable HTTP/2 on Apache?

~~~
igrigorik
See
[http://httpd.apache.org/docs/trunk/mod/mod_h2.html](http://httpd.apache.org/docs/trunk/mod/mod_h2.html)

------
mtgx
Now make those images webp.

------
rickjr1985
this HTTP 2.0 was faster for me by only .01 seconds.

