Why do some programmers argue for old solutions like sprite sheets when they are far worse? Here are some reasons why you shouldn’t use sprite sheets.

With the rise in the popularity and use of new web technologies like html5, css3, and ecma5.1-based JavaScript, new questions about best practices have come about. One of the biggest questions is around loading many images vs. loading one large image containing many images. This one large image that contains many images is known as a sprite sheet.

Sprite sheets have gained a lot of popularity in the last few years. They are touted as faster loading, easier to use and a better overall solution. Let’s take a look at each of these.

Sprite sheets do not help load time. They are based on the idea that fewer calls to the server will result in less latency and this is supposed to outweigh the difference that the increased file size will add to the load time. To maximize this effect you would want to load one file with all of the images in it. This means putting jpgs, pngs, and gifs onto one sprite sheet. The sprite sheet will need to be either a jpg or a png. If it’s a jpg then none of the pngs or gifs are optimized and file size is dramatically increased, not to mention the extra space around/between images. You could alternatively save it as a png which again increases file size for all images not originally png.

What if we made a sprite sheet for each image type? This is a big improvement on the file compression and it still reduces the number of calls to the server. However with sprite sheets the requirement is that once you put an image on the sheet you can’t take it off unless you replace it with an image of the exact same dimensions. Not to mention the extra space between images and at the bottom of the sheet. As images are added to the sheet over time, optimization on the sprite sheets begins to really break down.

What if the sprite sheet had fewer images on it to negate the effects of updating the sheet over time? This only takes us closer and closer to not using a sprite sheet at all, increasing the number of loads requested and we’re back to using separate images instead of sprite sheets.

What about caching? Caching helps separate image files and hurts sprite sheets. As images are loaded they are cached so that future calls to the image don’t incur the dreaded latency. Where this differs between separate images and sprite sheets is when you update the files. When you update a single image that one image has to be loaded. When you update an image within a sprite sheet… the entire sprite sheet has to be reloaded by the user. Essentially it wipes that cache for all the images used in the sheet. Which brings us to…

Sprite sheets are harder to use. When using an image you load it by its name, and place it where you want it. When using a sprite sheet you have a gridwork of x and y positions and widths and heights for the piece of the sprite sheet you want to show. Immediately sprite sheets are less friendly as they’re harder to understand when returning to edit and initially create your page. Then there’s the actual editing process. Normally you would upload a single file and link to it within your code. With a sprite sheet you will need to export your image, decide if it exactly matches a previous image that can be replaced by this new image, and if not put it at the bottom of your sprite sheet, re-optimize and re-upload an entire sprite sheet and then grab the x, y, width and height of the image within the sprite sheet. Once again, worse. What happens if you make an error? Well, normally the one image you’ve uploaded would be the only thing effected. With a sprite sheet. All of your images may be effected.

Sprite sheets are not the future, sprite sheets are the past. People think they sound like a genius for using more difficult solutions and if that solution is markedly better, then there’s some grounding there. This is not the case for sprite sheets. Browsers use http to make requests on servers and load images. Http can transfer one file at a time, meaning a browser would get the html file, then image 1, image 2, image 3, etc… but it had to wait for each file to load before it got the next file. This stacked latencies. So if each file had a 50ms latency and you were loading 20 files you would get 1000ms of latency. You just added a full second to your load time. In this way sprite sheets were a solution to staked latency. Modern browsers make 6 or more calls to the same server at the same time.  Meaning that if you had those same 20 files at 50ms of latency per file you’d end up with a max latency of 150ms or approximately 1/10 of a second. Not noticeable.

If you hear someone arguing for sprite sheets it’s possible that they haven’t caught up to the present and using them may cause longer editing times and overly complex code.