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