5 ms·
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.
by dlubarov 12y ago
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 :-)
- nl 12y agoThat's an extremely fair comparison because it shows how it is possible to avoid odd optimisations like the one you mentioned.
- venaoy 12y agoMany of the sites I visit frequently are exactly like that: tons of requests with tiny payloads. The nytimes.com homepage makes 100+ requests to tiny images. Same thing for the yahoo.com homepage. An ebay.com listing page makes many requests to small thumbnails of items on sale. And so on... This makes it a perfectly fair benchmark IMHO.
- dlubarov 12y agoI 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.