[swift]

It's true that images may compress more efficiently in some cases when combined into a sprite sheet, but in my experience the scenario described by the article is very likely: your sprite sheets will end up containing images that the current page doesn't need. That has significant costs in terms of bandwidth usage, memory usage on the client side, and CPU / energy usage on the client side (for decoding unneeded image data).

Further, if any image on the sprite sheet is currently visible, the entire sprite sheet must remain in memory, when otherwise the browser could free the memory of all the non- visible images. And it may sometimes be necessary to use a much more expensive drawing path when drawing sprites to ensure that pixels from one image don't bleed into another image.

These negative effects will be felt most severely on resource-constrained mobile devices, where it matters most.

One should always measure when making decisions about performance, but in an HTTP2 world my recommendation would be to avoid sprites in most cases.

[cabirum]

Sprite sheets contain images browser might need. Essentially it's a preloading technique, so you won't be slowed by waiting for something to load, even if it takes half a sec.

Also, most if not all browsers use GPU to render web pages. And spriting actually comes from gamedev/GPU world [1], where many textures are baked/combined into a big one because it's efficient from performance/memory layout POV.

A final thought, what about server IO becoming a bottleneck when it needs to read hundreds of small files from disk for each request?

[1] http://www.blackpawn.com/texts/lightmaps/

[swift]

HTTP2 supports server push, which should serve your needs for preloading just fine. (And there are other approaches as well; that's just one example.)

Browsers generally use the GPU for compositing web pages, but the CPU still generally does most of the rendering, and that frequently includes at least some of the image rendering. That's not actually relevant, though. The problem is bleeding; see here [1] for an example of someone encountering it in a gamedev context.

So how do you solve bleeding? If you read the answer to that Stack Overflow question, you'll see that it involves correctly setting up the data in the texture to avoid the issue. The problem is that browsers cannot assume that you've done that. The workaround depends on which graphics backend (OpenGL, D2D, etc.) is in use, but it can sometimes involve making a temporary copy of the region of the texture you're going to draw, which is obviously expensive.

As for server IO being slowed down by reading hundreds of small files from disk, I'd expect a properly configured server to be serving those files from memory, either explicitly or implicitly through the OS's filesystem cache.

[1] http://stackoverflow.com/questions/7894802/opengl-texture-at...