What's the idea behind image sprites, how to approach it?

Question

How do you approach the use of image sprites in css?

Should I take all the images in my website and combine them to one image sprite? Is it really that beneficial?

How hard is it to maintain those images and change them later on?

Answer 1

Sprites are a great way of cutting down load-time on graphics (sometimes), and always a way of cutting down requests to the server. Generally speaking, they may take some serious planning as you don't simply want to drop a bunch of images onto a canvas and export as a jpeg. I would suggest you study some sprites currently in use by larger companies like Amazon. Get an idea for how they layout their elements, and what types of images they even consider for use in sprites.

You'll also want to evaluate your site and be sure whether you can successfully implement them or not. If you weren't planning on using them to begin with, it may require a lot of back-tracking and updating to prepare for them.

1. Amazon Sprite
2. Ebay Sprite
3. Current.com Sprite (Whoa)
4. Google

Answer 2

Should I take all the images in my website and combine them to one image sprite?

Of course not. You're taking it too literal.

I find sprites are best used for groups of similar images. Examples include:

1. All states of a graphical button
2. States of icons
3. All permutations of a background (unless it needs to tile two ways)

Is it really that beneficial?

If you have a lot of them on a busy site, very. It saves a request for each image, saving the user time and your server a whole bunch of concurrent connections.

How hard is it to maintain those images and change them later on?

If you've used them logically, pretty simple. If you need to add another navigation item, you open up your nav sprite and expand it. For things like navigation it can actually be easier to maintain because you have like comparisons right next to you in the same document.

Edit, having seen one of the more extreme examples, I'll add that I would never go that far because:

• It's 60k to download. Not huge but on slow connections, that's 60k that has to be downloaded before anything shows. If all your visual assets are tied up, it can make the load time seem longer.

• Your CSS becomes a nonsensical mish-mash of background-position commands. If you do want to make changes you have to go back to the sprite and measure everything. Again and again and again.

• God have mercy on your soul if you need to enlarge something in the top-left of the sprite. You'd probably just add a new sprite below the current ones.

• And that might lead to bloat. Indeed, just loading all these images might be loading a whole lot of material that some users will never actually see. Loading unused data is probably worse than a connection overhead (considering how easily static content can be served by multiple cheap servers or a CDN)

The other examples are a lot more simple and worthwhile (IMO).

Answer 3

Sprites work well when you’ve got an element with at least one fixed dimension (width or height), and you want it to have a different background image in different circumstances.

When I’ve tried it, I’ve found that sprite image files tend to be smaller than the total size of the individual images files they’re made from, so you can get bandwidth savings as well as the other two benefits:

1. fewer HTTP requests
2. no delay waiting for another image to download when an image state changes on hover

That does depend on the contents of the images though.

Personally, I wouldn’t put unrelated images together in one sprite image, as I think it makes maintenance too non-obvious. Also, as mentioned in To Sprite Or Not To Sprite, really big sprite images can use quite a bit of browser memory. (Whether this is actually a bad thing depends on the context.)

Answer 4

The idea is to avoid unnecessary HTTP requests. This is especially an issue if you have a lot of small icons (say, for a WYSIWYG editor like the one used on this site). If you have twenty 16x16 pixel icons, that won't amount to much bandwidth, but it will still mean twenty extra requests each time the page is loaded.

Other candidates for sprites are button states and anything that's purely decorative but part of the layout.

If you use roll-over background image changes, you'll also find that you'll either have to preload the roll-over state image (either with JS or with silly hardcoding) or you'll encounter some latency as the browser requests the previously unused image. Sprites can alleviate that.

Things you probably shouldn't be making sprites of are pictures that are NOT just graphical elements (e.g. graphs, illustrations, avatars, ads) or that will change a lot (e.g. avatars or ads).

It's not impossible to change sprites, but depending on how much thought you put into the arrangement of the sprite sheet, it may be very hard to do. There's nothing forcing you to make the sprite sheet ultra-condensed, but it's obviously better for the file size if there's not much unnecessary whitespace in it (see Google).

Note that the extra requests may not be a problem for you if you have a relatively low traffic site (which almost everybody has, unless you're Google or Amazon). Sprites may still improve performance for mobile devices, though, as it means less chances for errors and thus lower latency.