Does using image sprites make sense in HTTP/2?

Question

The bundling of JS and CSS files won't be necessary in HTTP/2, but what about image sprites?

Looking at the demo it seems that it already works way faster than HTTP/1.1, but won't bundling images into sprites make it even faster? I mean, won't the PNG's optimization algorithms work better when all the data is in a single file?

Tuchun

Answer 1

It depends of your image(s) sizes and format. If the images are big enough, you won't gain much by using sprites, but for small images there are significant gains, even when using HTTP/2. What makes HTTP/2 better is that there is much less overhead for headers and potentially even less round-trips (provided the server implements PUSH). The question is, how small should your files be to consider bundling them?

For bitmaps, you make a good point in that PNG's optimization algorithm works in favor of sprites, specially if their size is small enough. For example, while the image in this article from Gabriel Bouvigne is 17.4 kb, slicing it produces 132 separate images totaling 135 kb. When you add a small but nonetheless existing additional overhead for transfer, it's close to a factor of ten. And yes, size still matters when the bandwidth between the server and client is limited.

Actually, this also reaches text resources, like javascript, css, and SVG files. If they are small enough and they don't change frequently, you may still consider bundling them together. For example, the Javascript in the ng folder of Angular's source takes 69.6 kb if transferred as separate, minified and gzipped js. If you concatenate them before gzipping, it is just 31.9 kb. The factor here however is just slightly above two, and it may not be as significant if HTTP/2 saves connection time and round-trips. That further balances with the possibility of caching resources separately.

As a final note, if your small images/icons are SVG vectors (and they should!), then they count as text resources. Also, SVG vectors tend to be a bit bigger, for example, Firefox's SVG icon is 15.7 kb when gzipped. At this size, the decision of linking to it vs inlining or bundling is a no-brainer, if the HTTP/2 goodies are working.

Psychopathy

One thing that I feel is worth adding, is that while you might be right when you're considering total sizes, not using spritesheets does allow a client to only fetch the images that are actually used in a particular page. Bundlings means you're sending everything, whether it's used or not. – Intendant

Answer 2

I will agree with @dsign that it depends.

There's a trend towards inlining the types of small images that would normally be used as sprites within the CSS itself as data-urls. If you're inlining your images into CSS, just keep them as separate entries, this also has the advantage of per-image optimizations. Optimizations for one image in a sprite don't match others... with PNG, you can opt for potentially lossy conversion into an image at/under 256 colors with alpha transparency layers such as TinyPNG and pngquant. some images can go under 16-colors. When you are creating a combined sprite, these kinds of optimizations are more limited.

I'm leaning towards either simply using CSS inlining or keeping images separate. The positive is that tools like webpack (and others that people are moving towards) makes this a fairly trivial configuration matter for web applications.

If you're in a position to implement server-side push for images via HTTP/2, then keeping them separate more likely works in your favor.

Rollback