HTTP/2 vs HTTP/1.1 for a Grid of Thumbnails

Pages with many small images, such as product grids, galleries and lists of thumbnails, used to suffer under HTTP/1.1, because a browser opens only six connections per site and each connection carries one request at a time. HTTP/2 sends all requests over one connection at once. Does that make a grid of thumbnails load faster, and does it change which images appear first? We loaded grids of 12, 36 and 72 thumbnails over both protocols.

The test

Each page shows a four-column grid of the same 400-pixel CC0 JPEG thumbnail (13.2 KB), with a unique URL per image so none is cached. Two local servers served the pages: one over HTTP/1.1 without encryption, one over HTTP/2 with TLS, as browsers require for HTTP/2. Each grid was loaded five times per protocol in Chrome 155.0.8059.82 on a desktop viewport, once on a throttled 4G profile (1.6 Mbit/s, 150 ms latency, CPU 4× slower) and once without throttling. We recorded when the first and the last image finished downloading. See our methodology.

Results

HTTP/2 finished the whole grid 13–16 % sooner on the throttled connection. With 72 images, the last one arrived at 5,212 ms over HTTP/2 against 5,983 ms over HTTP/1.1; with 36 images, 2,789 against 3,332 ms; with 12, 1,167 against 1,335 ms. On the fast connection the two were within a few milliseconds to 30 ms of each other.

But HTTP/2 delivered the first image much later. Over HTTP/1.1 the first thumbnail was complete after about 750 ms, regardless of grid size, because six connections each download one whole image at a time. Over HTTP/2 the images shared one connection and downloaded side by side, so they all progressed slowly together: with 72 images the first one finished at 4,332 ms, almost six times later.

That is the trade-off: HTTP/1.1 fills a grid image by image; HTTP/2 brings everything in at once and finishes sooner overall, but each individual image takes longer.

What this means for image-heavy pages

• HTTP/2 is the better default for many images, with the whole set done 13–16 % sooner here, even including the TLS handshake that the HTTP/1.1 server did not need.
• Lazy loading matters more under HTTP/2. If 72 images compete for bandwidth, the ones in view arrive later. Lazy-loading everything below the first screen, as in our lazy-loading test, keeps the visible images from sharing the connection with invisible ones.
• Priorities help when one image matters most: Chrome gives in-view images higher priority, and fetchpriority="high" can raise the main image further, as discussed in our fetchpriority test.
• Old HTTP/1.1 tricks are unnecessary. Spreading images over several domains or combining thumbnails into sprites was meant to get around the six-connection limit; HTTP/2 removes it.

Practical conclusion

Over HTTP/2, a grid of 12 to 72 thumbnails finished 13–16 % sooner than over HTTP/1.1 on a throttled connection, but the first thumbnail appeared up to almost six times later because all images shared the bandwidth. Use HTTP/2 and lazy-load images outside the first screen so the visible ones are not slowed by the rest.

Limitations

Local servers with Chrome’s network throttling, which adds latency per request rather than modelling real TCP behaviour; on real mobile networks, connection setup and packet loss affect both protocols differently. All thumbnails were identical in size. HTTP/3 was not tested.

Data and files

Download h1-vs-h2.csv (12 rows, 0.4 KB) · Method: testing methodology. Photo: image credits.