Not really a fair benchmark. It's making tons of requests with tiny payloads, so that most browsers will hit a connection limit and requests will be queued up.
Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript.
On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)
I don't know how you're assessing those pages, but bear in mind that
- Counting images can be misleading, since well-optimized sites use spritesheets or data URIs.
- If you're using something like Chrome's dev console to view requests, a lot of them are non-essential requests which are intentionally made after the page is functional.
- HTTP connection caps are per host. The benchmark is making hundreds of requests to one host, whereas a real page might make a dozen requests to the main server, a dozen to some CDN for static files, and a dozen to miscellaneous third parties.
- The benchmark is simulating an uncached experience; with a realistic blend of cached/uncached, HTTP 1 vs 2 performance would be much more comparable.
HTTP/2 is an improvement but if people expect a "5-15X" difference, they're in for a big disappointment.
Heavily optimized pages like google.com use data urls or spritesheets for small images, and inline small css/javascript.
On the bright side, reducing the need to minimize request count will make our lives as developers a bit easier :-)