Under what circumstances would loading images individually with HTTP/2 be slower than loading all images at once with a sprite a la HTTP/1.1?

Question

HTTP/2 makes it possible to multiplex connections, eliminating the need for more than one connection to a server. Over a single connection, many individual images can be sent down to the client. This obviates the old image sprite pattern of combining many images into one and using CSS to cut it apart.

I'm curious if sprites would still actually be faster in an HTTP/2 world. If so, under what circumstances?

Post

Answer 1

Sprites, as you will know, are used to prevent multiple requests being queued, so with one payload you could get all the sprites for the site.

But with sprites you tend to get lots of additional icons that are used throughout the website that aren't all needed on any single page.

So with http/2 multiplexing, queuing resources is no longer an issue. You get the speed benefit when you only download the files needed for each page.

However you may get better compression by combining some images into a single file, making the overall size of file transfers smaller.

Speed tests run by Benoît Béraud and Alexandre Masselot have given an example of a sprite sheet loading faster than individual sprites. They concluded that sprite sets can still be used to optimise site performance when using http/2 http://blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead/

Extended write up about http/2 by Rachel Andrew can be found here: https://www.smashingmagazine.com/2016/02/getting-ready-for-http2/

Boulanger

This isn't a bad hypothetical, but it's hard to imagine compression making that much of a difference to outweigh the benefit of loading images individually over H2. If it does, I suspect that it'll be under very contrived circumstances. Would make for a good research topic. – Post

For sprite speed tests you might be interested to read: blog.octo.com/en/http2-arrives-but-sprite-sets-aint-no-dead – Boulanger

Answer 2

With HTTP/2 multiplexing, the server will be reading a lot of small files instead of reading a single big file. If the server is resource-limited (some Internet-of-Things contraption, for example), then you might be able to find a situation where it's better to have it making the single, big read instead of a lot of small ones, since each read causes the server OS to potentially do a lot of file-access-related operations.

On the client side, the browser will be managing a lot of small files, instead of a big one. I can imagine the code path used for the current sprite workflow being well massaged and optimized, since it's so commonly used. So it might happen that the new case of having a lot of small files could be slower, at least for a time.

Fronnia