Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

CSS Sprites: Useful Technique, or Potential Nuisance?

Ah, the ubiquitous CSS sprites — one of the few web design techniques that was able to bypass “trend” status almost instantly, planting itself firmly into the category of best practice CSS. Although it didn’t really take off until well after A List Apart explained and endorsed it1, it was discussed as a CSS solution as early as July, 2003 by Petr Stanícek2.

Most web developers today have a fairly strong grasp of this technique, and there have been countless tutorials and articles written on it. In almost every one of those tutorials, the claim is made that designers and developers should be implementing CSS sprites in order to minimize HTTP requests and save valuable kilobytes. This technique has been taken so far that many sites, including Amazon3, now use mega sprites.

You may also want to take a look at the following related posts:

Is this much-discussed benefit really worthwhile? Are designers jumping on the CSS sprite bandwagon without a careful consideration of all the factors? In this article, I’m going to discuss some of the pros and cons of using CSS sprites, focusing particularly on the use of “mega” sprites, and why such use of sprites could in many cases be a waste of time.

Browsers Cache All Images Link

One of the benefits given by proponents of the sprite method is the load time of the images (or in the case of mega sprites, the single image). It’s argued that a single GIF image comprising all the necessary image states will be significantly lower in file size than the equivalent images all sliced up. This is true. A single GIF image has only one color table associated with it, whereas each image in the sliced GIF method will have its own color table, adding up the kilobytes. Likewise, a single JPEG or PNG sprite will likely save on file size over the same image sliced-up into multiple images. But is this really such a significant benefit?

By default, image-based browsers will cache all images — whether the images are sprites or not. So, while it is certainly true that bandwidth will be saved with the sprite technique, this only occurs on the initial page load, and the caching will extend to secondary pages that use the same image URLs.

Firefox Cache
The Firefox cache displaying images from that the browser cached (type “about:cache” in the address bar in Firefox to view this feature).

When you combine that with the fact that internet speeds are higher on average today than they were when this technique was first expounded upon in 2003-2004, then there may be little reason to use the mega sprite method. And just to be clear, as already mentioned, I’m not saying sprites should never be used; I’m saying they should not be overused to attain limited benefits.

Time Spent Slicing a Design Will Increase Link

Think about how a simple 3-state image button sprite is created: The different states need to be placed next to one another, forming a single image. In your Photoshop mockup (or other software), you don’t have the different states adjacent to each other in that manner; they need to be sliced and combined into a new separate image, outside of the basic website mockup.

If any changes are required for any one of the image states, the entire image needs to be recompiled and resaved. Some developers may not have a problem with this. Maybe they keep their button states separate from the mockup in a raw original, making it easier to access them. But this complicates things, and will never be as simple as slicing a single image and exporting it.

For the minimal benefit of a few kilobytes and server requests saved (which only occurs on initial page load), is the mega sprite method really a practical solution for anything other than a 3-state button?

Time Spent Coding and Maintaining Will Increase Link

After an image is sliced and exported, the trouble doesn’t end there. While button sprites are simple to code into your CSS once you’re accustomed to the process, other kinds of sprites are not so simple.

A single button will usually be a <ul> element that has a set width. If the sprites for the button are separate for each button, it’s simple: The width and height of the <ul> will be the same as the width and height of the list item and anchor, with the sprite aligned accordingly for each state. The position of the sprite is easily calculated based on the height and/or width of each button.

But what about a mega sprite, like the one used by Amazon, mentioned earlier, or the one used by Google8? Can you imagine maintaining such a file, and making changes to the position of the items in the CSS? And what about the initial creation of the CSS code? Far from being a simple button whose state positions are easily calculated, the mega sprite will often require continuous testing and realigning of the image states.

CSS for Google's sprite9
Some of the CSS used to position Google’s sprite image

It’s true that the Amazon sprite saves about 30 or more HTTP requests, and that is definitely a significant improvement in performance. But when that benefit is weighed against the development and maintenance costs, and the caching and internet speed issues are factored in, the decision to go with sprites in the mega format may not be so convincing.

Do Sprites Really Require “Maintenance”? Link

Of course, some may feel that sprites do not cause a major headache for them. In many cases, after a sprite is created and coded, it’s rarely touched again, and isn’t affected by any ongoing website maintenance. If you feel that sprite maintenance won’t be an issue for you, then the best choice may be to use the mega sprite method.

Not Everything Should Be a Background Link

Another reason not to promote the overuse of CSS sprites is that it could cause developers to use background images incorrectly. Experienced developers who consider accessibility in their projects understand that not every image should be a background. Images that convey important content should be implemented through inline images in the XHTML, whereas background images should be reserved for buttons and decorative elements.

Amazon correctly differentiates between content and decoration
Amazon correctly places content images as inline elements, and decorative ones as backgrounds.

Improper Use of Sprites Affects Accessibility Link

Because of the strong emphasis placed on using CSS sprites, some beginning developers intending on saving HTTP requests may incorrectly assume that all sliced images should be placed as backgrounds — even images that convey important information. The results would be a less accessible site, and would limit the potential benefits of the title and alt attributes in the HTML.

So, while CSS sprites in and of themselves are not wrong, and do not cause accessibility problems (in fact, when used correctly, they improve accessibility), the over-promotion of sprites without clearly identifying drawbacks and correct use could hinder the progress the web has made in areas of accessibility and productivity.

What About HTTP Requests? Link

Many will argue10, however (and for good reason) that the most important part of improving a site’s performance is minimizing HTTP requests. It should also be noted that one study conducted showed that 40-60% of daily website visitors come with an empty browser cache11. Is this enough to suggest that mega sprites should be used in all circumstances? Possibly. Especially when you consider how important a user’s first visit to a website is.

The YSlow Firefox add-on that analyzes performance shows the number of HTTP requests being made

While it is true that older browsers generally only allowed two simultaneous HTTP connections, Firefox since version 3.0 and Internet Explorer 8 by default allow 6 simultaneous HTTP connections12. This means 6 simultaneous connections per server. To quote Steve Souders:

It’s important to understand that this is on a per server basis. Using multiple domain names, such as,,, etc., allows a web developer to achieve a multiple of the per server connection limit. This works even if all the domain names are CNAMEs to the same IP address.

So, while there could be a benefit to using CSS sprites beyond just button states, in the future, as internet connection speeds increase and newer browser versions make performance improvements, the benefits that come from using mega sprites could become almost irrelevant.

What About Sprite Generators? Link

Another argument in favour of mega sprites is the apparent ease with which sprites can be created using a number of sprite generators13. A detailed discussion and review of such tools is well beyond the scope of this article, so I’ll avoid that here. But from my research of these tools, the help they provide is limited, and maintenance of the sprites will still take a considerable amount of work, which again should be weighed against the benefits.


Some tools, like the one by Project Fondue15, offer CSS output options. Steve Souders’ tool SpriteMe16 is another one that offers CSS coding options. SpriteMe will convert an existing website’s background images into a single sprite image (what I’ve been referring to as a “mega” sprite) that you can download and insert into your page with the necessary CSS code. While this tool will assist with the creation of sprites, it doesn’t seem to offer much help in the area of sprite maintenance. Souders’ tool seems to be useless for a website that is redesigned or realigned, and only seems to provide benefit to an existing design that has not yet used the mega sprite method.

CSS Sprite Generator by Project Fondue17

Improvements to current tools could be made, and newer tools could appear in the future. But is it possible, due to some of the drawbacks mentioned above, that developers are focusing a lot of effort on a very minimal gain?

Focus Should be on Multiple Performance Issues Link

As mentioned, the number of HTTP requests is an important factor to consider in website performance. But there are other ways to lower that number, including combining scripts and stylesheets, and using remote locations for library files.

There are also areas outside of HTTP requests that a developer can focus on to improve site performance. These might include GZipping, proper placement of external scripts, optimizing CSS syntax, minifying large JavaScript files, improving Ajax performance, avoiding JavaScript syntax that’s known to cause performance issues, and much more.

YSlow's multiple performance recommendations
YSlow indicates many areas outside of HTTP requests that can improve site performance

If developers take the time to consider all factors in website performance, and weigh the pros and cons correctly, there may be good reason to avoid overusing CSS sprites, and focusing on areas whose performance return is worth the investment.

Conclusion Link

Please don’t misinterpret anything that I’ve said here. Many top bloggers and developers have for years extolled the benefits of using sprites, and in recent years taken those suggestions further in promoting the use of mega sprites — so those opinions should be taken seriously. However, not everyone has the luxury of working in a company that has policies and systems in place that make website maintenance tasks simple and streamlined. Many of us work on our own, or have to inherit projects created by others. In those cases, mega sprites may cause more trouble than they’re worth.

What do you think? Should we reconsider the use of mega sprites in CSS development? Do the statistics in favour of the savings on HTTP requests warrant the use of sprites for all background images? Or have sprites in CSS development evolved from a useful, intuitive and productive technique to a time-consuming nuisance?

Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17

↑ Back to top Tweet itShare on Facebook

Louis Lazaris is a freelance web developer and author based in Toronto, Canada. He blogs about front-end code on Impressive Webs and curates Web Tools Weekly, a weekly newsletter for front-end developers.

  1. 1

    “A single button will usually be a element that has a set width.”

    on what planet?

  2. 2

    Had no idea about CSS sprites :-) Ok, I’m not a web designer but thanks for enlighten me.

  3. 3

    You argue that css sprites only save time on the first pageload when there’s no cached data and thus has limited benefit. This is false. If the user has no cached data, that usually means they are newcomers to your website and the first impression is what fundamentally forms their opinion about your website. A fast loading website is extremely important when it comes to the first impression so it shouldn’t be overlooked just because caching will hide any optimization later…

  4. 4

    I do use sprites in targeted areas with great benefit in terms of load times, etc. I have written my own java code to build the sprite and css files needed.

    However, I have for a long time wished that http supported retrieval of resources within a zip. In other words:

    < img src=”!big/edit.png” >
    < img src=”!big/delete.png” >
    < img src=”!small/help.png” >

    First image triggers the “” to be downloaded, then pulls out and displays “bigIcons/edit.png” from within that zip. Then the rest just pull the image out of the cached zip.

    This would not save the browser the rendering time benefits of sprites, but it would definitely address the multiple http request issue. And it would be a gigantic time saver on the web-dev side in terms of avoiding having to maintain a sprite file and coordinate pixel positions. I could imagine web platforms rapidly baking this in so that it is automatic.

  5. 5

    Der Rote Hund

    March 26, 2010 6:42 am

    “[…]this only occurs on the initial page load, and the caching will extend to secondary pages that use the same image URLs.”

    True, but most pages loaded in real life *are* first pages. Look at your statistics and you’ll find most people don’t look at more than one page on your site.

    Also, you forget to mention the saved bandwidth for the server. While the client might only load your page once and savings for a single user are minimal, multiply that by the amount of pages that are served and the savings in server-bandwidth become substantial.

  6. 6

    I’m sorry but this is the worst article I’ve read on Smashing… You’re turning people off of using a perfectly valid technique using nothing more than opinion. If you’re going to be a skeptic and make a valid argument you need to provide some facts and figures. Every section just seems to end with a loose conjecture as to why sprites are bad but without any numbers or even anecdotal experiences to reinforce the conjecture.

    I use sprites every day. We have set rules for when to use sprites and when to use single images. Backgrounds, visual accents, borders, and icons are all in the sprite. Content or anything that needs to be tagged to be accessible (e.g. product images) are separate files.

    The way to do it right is to stay organized. 1) Use a generator it’s not the devil. OR 2) If you’re going to maintain the code yourself your PSD or SVG graphic should have regions of related content with some directional order and plenty of guides as reference points. For example, the sprite I use most often has the site header, body background, and footer as the upper half of the image. Then the lower half right quadrant contains form buttons going from smallest on the left, to largest on the right, then the various button states going down with default on top, then active, and disabled at the bottom. Then the other quadrant of the sprite has icons, checkbox states, and other backgrounds organized into similar zones. For any group of items I’m only dealing with 1 axis, so all of the toolbar icons have a background position of X -255px and all I need to do is increment X by 24px for each toolbar button.

    As long as you’re organized it’s easy to start at some base line and then with simple math, position your sprite. If new images are added to the sprite, hopefully you’ve organized things in such a way that you have room or can shift existing content in a single axis to make room and therefore limit the number of changes required to the CSS.

    Increasing the browser parallel connections to 6 helps from having just 2, but today’s sites can have 20+ core images and then 20+ more secondary images to download over the course of a visit (not to mention extra CSS files, content images, and JavaScript files). So 6 connections will reduce the load time somewhat, but you will still have delays and still be using up server resources unnecessarily. The way to look at this is by the volume of the traffic on the server. Would you rather have 1,000,000 users making 1 request each for your 70k graphic or 1,000,000 users making 40 requests each for your 90k worth of separate graphics. You can do the math on the bandwidth savings as well, as each request consumes a few more bytes to make.

    Does the bandwidth and CPU cost negate the maintenance cost over time? In fact, the real question to ask is, is there a higher maintenance cost to maintain the sprite versus slicing images and maintaining separate images over time? With a sprite I don’t need to slice and name separate images, come up with a naming convention or deal with name conflicts, or have the program produce generated code for me which may not be maintainable, nor do I have to insure that the n number of new images got checked in to version control or successfully uploaded to the server with the last build, and I’m most likely saving some bytes in the CSS not needing separate listings for background for n number of images. Instead I have ONE image site.png and ONE CSS file to contend with, and again if I use simple math and stay organized, maintenance is a breeze, and at least for me it’s reduced my development time not having to maintain separate images.

  7. 7

    >Browsers Cache All Images
    First of all, it doesn’t necessarily cache anything. It depends on the settings done on the server.
    Second, you claim that CSS sprites are superfluous because the images get cached by the browser, yet you go on to contradict yourself later on by stating that 40-60% of the users come in with a blank cache.

    >Time Spent Slicing a Design Will Increase
    Nonsense. You wouldn’t spend more time creating a 3-state button sprite than you would slicing it up into different images. It’s not the concept that is flawed, it’s your method. What you should do is create a blank document, place it side-by-side to your mockup and simply drag over the layers you need. Once you’re done dragging the layers around in the order you want them, you save the image. No need for slicing, saving and loading back and forward.

    >Time Spent Coding and Maintaining Will Increase
    You claim that a CSS sprite would have to be separate for each button in order to be maintainable. This is of course false. A CSS sprite doesn’t stop working simply because you add information to it. The existing image areas would be in the same place, and so would the CSS code referencing these areas.

    Of course you’d get some additional development time, but how much are we really talking about here? Do you really spend hours summing up the widths and heights trying to calculat a position within a CSS sprite? NO. You spend a few seconds doing this. And you already know the benefits of doing this. And yet somehow “when that benefit is weighed against the development and maintenance costs, and the caching and internet speed issues are factored in, the decision to go with sprites in the mega format may not be so convincing.” Really? Does a few seconds really make that much of a difference for you?

    >Improper Use of Sprites Affects Accessibility
    This is not an issue with CSS sprites, this is an issue with people blindly applying background images in general (yet somehow you have a problem with the former, but not the latter?). Anyway, the functionality of alt text and title is NOT lost with CSS sprites. The alt text would be the text hidden with CSS (which is still accessible by screen readers, assuming you haven’t used some funky stuff involving introduction of markup and display: none) and the title attribute can be applied on the element.

    >What About HTTP Requests?
    Here, you completely forget two factors:
    * User Experience (the hover image won’t load until you actually hover over the element, adding waiting time until the image is displayed, and, in the meanwhile, turns the element invisible. This is not a problem with CSS sprites).
    * The fact that the website might be viewed on alternative browsing devices, such as mobile phones.

  8. 8

    I recently finished up a project in which I used CSS Sprites for two significant parts of the website. I actually find myself on the other end, not using them much at all, but only when I feel the are required. The project needed uneven rollovers, and using the technique that I learned about oh-so-long ago in the A List Apart article, I ended up with some nice menus that will degrade nicely as well.

    I don’t trust “Sprite Generators”, not to say they aren’t good for some people, but I feel they are more trouble than they are worth.

    CSS Sprites can definitely improve accessible design, but I also feel they can easily be overused.

    Thanks for getting my brain going this morning! Your article has been working faster than my coffee!

  9. 9

    Great and very detailed explanation.. I still prefer using sprites on buttons. It makes the loading of the states much faster. I haven’t tried using mega sprites though. Nice!

  10. 10

    Joshua Brown

    March 26, 2010 4:55 am

    I generally use sprites for nav buttons, input buttons, and a few other interactive decorations. This technique has drastically improved my coding time, I find that maintenance is easier, and I just think it’s more elegant than using separate images.

  11. 11

    I’m a sprite lover and always use it with care. I think it could be a nuisance since the sprite first made is like the google/amazon. But when I need to do a “mega sprite” (like you said) I try to put every image or state of buttons organized from top-left to right (or bottom), that assures me no need to recalculate background-position for each sprite. Let’s call it “re-sprite”. lol

    Amazing article!

  12. 12

    Come again? Do you use buttons that change width? I cant imagine that looks very good except for using fancy effects that are unnecessary.

  13. 13

    NIels Matthijs

    March 26, 2010 5:04 am

    Biggest problem with sprites is that pixel formats just don’t go well together with flexible formats. And I’m not even talking about ems, even distances in a fixed design are prone to change.

    What’s lacking in the current specs is to only show a certain cut-out of a picture. Current implementations of css sprites require you to hide all the other elements outside the box. Only when we can control what part of an image to show through css, css sprites will start showing their real value.

    Until then, bad practice except from some very controlled situations (icons with no text for example, which will always have the same width).

  14. 14

    Great article that opens up a discussion and make us think about it, love it !

  15. 15

    Geoff Jackson

    March 26, 2010 5:05 am

    I’m no designer by any means but I recently just did my first piece of work using sprites ( scroll down to see the SEO, PPC and Social Media buttons and hover the mouse over them.

    I’m quite pleased with the outcome although I can imagine when using this method throughout a whole website, it could take ages :/

    Feedback appreciated though :p Heh

  16. 16

    Lennard Schutter

    March 26, 2010 5:10 am

    Actually all of my buttons have a variable width. Using slider buttons it isn’t that hard to do. What would you do if you have a button with the text: “Click here to order this product”? Make a seperate image for it?

    I don’t agree that different widths in buttons are ugly at all, i even think it’s more ugly to have lot’s of unused space inside your button.

    I know it’s easy to make a fancy button with CSS3, but our MS friends don’t support that, so i use images to at least get some design in my buttons.

  17. 17

    Multilingual website?

  18. 18

    I use Image Sprites for navigation buttons. I create a PSD file with the different states in it and by simply changing the text layer I find it pretty easy to maintain. I never used a “mega sprite” ’cause I find it hard to maintain. If you use a image sprite for each button you can also combine CSS statements.

    Here’s an article I wrote:

  19. 19

    It didnt copy the part i was referencing…. the ul portion.

  20. 20

    If you’re manually generating sprites, you’re doing it wrong. Look, we’re in the year 2010. You shouldn’t have to calculate pixels on a custom sprite. That’s a serious misuse of time. What Amazon probably does is generate these sprites by CODE (ie. the 21st century method). I’ve written an article in the past on how to generate sprites in C# ( In my implementation, you just add an image to an images folder, use pre-defined CSS and the caclulation of the position and the generation of the sprite is just taken care of. That’s how it SHOULD be.

    So, to recap, I could not disagree with some of your points more. CSS sprites are beneficial to reducing HTTP requests. Think about it. The average site has OVER 6 images on a given page. Your argument about concurrent connections doesn’t really hold. A site usually has at least a single Javascript file, the page itself, CSS file, images… the list goes on. You want to be stingy with these connections. People have documented significant performance improvements with CSS sprites. Just because we now has 6 concurrent connections on a browser doesn’t mean we can throw out one of the best optimizations that has saved a LOT of bandwidth. I’m going to keep using “mega-sprites” because I’ve seen significant improvmenets.

  21. 21

    Rene Schmidt

    March 26, 2010 5:35 am

    Sprites are a pain in the a**… But you can drastically improve loading times. It can make a huge difference loading 1 file instead of 30. However I would recommend sprites only for sites with lots of visits.

  22. 22

    Nice article, but I have to disagree with the last bold statement.
    Using mega sprites ARE worth the effort!

    But of course you have to adjust your photoshop workflow in order to cleanly maintain the contents within your PSD file.

    Using a clear layer naming/grouping, grids and guides it’s very easy to maintain a sprite that contains a couple douzend graphics.+

    @jlarson: I like the idea, but: This means you have to load an applet in the browser right? I guess the time and performance it takes to start the JVM will exceed the additional loading time of more HTTP requests by far. And not every browser supports Java.

  23. 23

    I prefer sprites but not all the images in one sprite. For example I’m gonna use a sprite for the main menu, one for the secondary menu, one for arrows etc.

  24. 24

    Andrew Polhill

    March 26, 2010 5:48 am

    As stated one of the primary purposes of using sprites is to cut down the number of HTTP requests. The delay caused by downloading images is vastly increased where latency is an issue, (i.e. where the server is a long way from the customer). I am currently working on a project where our customer base is solely in the UK, as are our servers, in this case I am less tempted to use sprites.

  25. 25

    Edison A. Leon

    March 26, 2010 5:54 am

    Yeah, I think you have a very strong point. I’ve never use mega sprite yet (and I might never go that way thanks to your research), I think you are right maintenance can be a b*h so one thing I’ve doing while dealing with sprite is cutting in few image like background only, navigational only, buttons only, so that makes my job easier and in case I need to change size for one button since I don’t have to change position but just the buttons rules.

  26. 26

    I like the examination of a common practice. I personally use sprites only for roll-over buttons and things like that. If nothing else i like to avoid that little delay the first time you visit a site with a clean cache and roll over a button. It may be a small detail but like you mentioned the users first experience is an important one.

  27. 27

    Sprites probably load a little bit faster from the cache, too. Reading one image from the cache should be faster than reading 30 images.

    Of course, designers will make a few mistakes until they master it and learn how to organize images. The technique itself is brilliant, simple and clean, so I use it everywhere I can.

  28. 28

    Just to show that I’m not the only one making the claims in this article, here is a quote from an article by Jon Hicks in the December, 2009 issue of .net Magazine (Practical Web Design), page 50. The article is about icon design on web pages:

    Finally, adding the icon to your site involves a simple <img> tag, but I’m sure you’ll also have come across an alternative: CSS sprites. This is where you combine many images (or states of images) into one file to reduce http requests, resulting in faster page load. These are then placed and positioned using the background-image property in your CSS file. Apple uses a sprite that contains all the icons and button backgrounds for its MobileMe service. It’s a whopping 32×6,402 pixels, but only 52k for the lot.

    There are pros and cons to this technique, and the method you should use depends on the context. Sprites do speed up the initial page load and fit well with the philosophy of ‘designing in company’. However, they also increase development time and working out all the various background positions can be a real pain. Sprites aren’t too happy with text-resizing either, and it can be hard to avoid other ‘hidden’ images being revealed without adding large swathes of empty space to the image. Most importantly, though, you lose the alt attribute. If the icon is merely a decoration, or supported by text, this isn’t an issue. Consider what would happen if the CSS file or images didn’t load (due to user preference or intermittent internet connection).

    So, are sprites worth it? Once all the icons are loaded, they’ll be cached, so it really only speeds up the initial page load. However, you might have different states of an icon (hover, pressed etc) that aren’t visible initially. In these situations, CSS sprites are worth the effort, because these states can be preloaded…

    I had to type that all myself, because the article is not available online.

    And honestly, I actually got the idea for this SM article from those couple of paragraphs. I felt it was a very good argument against those who choose to use mega sprites in all circumstances, and I wondered why nobody had made those points in a more prominent fashion, so I decided to do it myself.

  29. 29

    Sprites can be a pain in the a** true, but they are 100% useful for templated images (such as navigation, re-used icons, fixed buttons) for many of the reasons mentioned in the article.

    For any eComm site… Time = Monday and this is a way to cut down on requests and look-up times. I’d almost venture to say that maintaining 15 smaller files is more of a pain than one sprite.

  30. 30

    I started using sprites about 6 months ago and I have since designed 4 websites using a combination of sprites and inline images when appropriate. Keep in mind that I am a critical thinker and when I design and code a website I don’t just think about the here and now, I utilize forward thinking. Forward thinking allows me to plan for the future growth of the website. With this in mind I try to make sure that my sprites and css are flexible enough to support additional or changing content without having an overly bloated sprite or css.

    I have found that when designing a website utilizing sprites there are other advantages outside of the normal fewer http requests. For example, I consider working with one image (sprite) less cumbersome than dealing with multiple images (slices or separate image files). Basically, when working with one image versus a dozen or more images I have noticed that I spend a lot less time organizing, naming and linking images.

    How do I make my sprites flexible enough for future growth or content changes? I plot my sprite and clearly define sections for the website content. As an example, I place all my buttons and their rollover states in a section devoted only to these buttons. To allow room for additional buttons I use white space, and if you can’t handle the white space, maybe this is not the best method for you.

    Some of my methods will not work for everyone, but in the end it’s a matter of preference. So, as long as the needs of your client are being meet and you create the best possible online experience for their audience, you did your job.

  31. 31

    Patrick Daly

    March 26, 2010 6:24 am

    While you agree that there are performance benefits to sprites your weightiest argument against sprites is that it makes for more work for the designer/developer.

    I’m all for efficiency and working quickly, but not at a client’s expense. If I know that I can make their site load faster then I’ll do it — even if it adds *15 minutes* to the task. That’s my issue here. Splicing and coding a sprite doesn’t take much more time. I could hear you out if this were an all-day project.

    That said, I don’t use sprites enough — thanks for the encouragement to start using them more. ;)

  32. 32

    As always, it depends. Webdesigners should know the technique, use it, but not always for everything.

    It’s true, that css srites decrease images size, http requests. The http requests are important even when files are cached. Browser has to check if the cached file is fresh, up-to-date.
    The size is important only once per user, after that visitor has the file cached.
    But the first impression counts.

    Something about css sprites at my blog (for now only in pl language, but I will add en version later on):

  33. 33

    One place CSS sprites should always be used is on multi-state buttons & navigation (ie: normal, hover, clicked). Without sprites, users see a gross “flicker” when hovering over the button for the first time, as the hover image takes a moment to download.

  34. 34

    Look into server-side GZipping.

  35. 35

    I’m sorry but that’s simply factually incorrect – they do just as-good-a-job as you could do yourself in Photoshop :)

  36. 36

    I feel sprites continue to be a must for interface design. What about the potential screen flash of images within for navigational hover states? Sprites generally eliminate this sort of image flicker.

    They also save calls to the server (as mentioned in the YSlow portion of this post), which is the same reason we should be writing as much CSS in one file as possible.

    So long as the sprite is set up with care & intention (both in Photoshop and in CSS files), maintaining updates to the sprite in a PSD is sweat free for me.

  37. 37


  38. 38

    While you do make some valid points, especially on choosing which images to be sprited and which not to, some is invalid.

    (1) The amount of extra work to work with sprite is not as much as you said it will. You also deride the CSS sprites generator (well, that’s probably why you think the amount of time needed to work with sprites is horrendous). Good CSS sprites generator can literally churn out a sprite and CSS file that contains configurable class names you can use in your design. You can also work with the unsprited images during development as what you are using is only the CSS class names and you can substitute the CSS files with one that use the unsprited images. With a build system in place, you don’t even need to do this.

    (2) While there are other means to improve front end performance, CSS sprites typically give the most benefits. A lot of websites contain small images that create huge number of HTTP requests, slowing down the browser loading AND burdening the HTTP server. The same website typically only have a few JS files and 1 CSS file. Combining all these small images do wonders. (OTOH, I agree completely with your Kindle examples.)

    On the other hand, you also did not mention the main drawback of your so-called “mega” sprite:

    Over-spriting reduces concurrency (in the form of parallel download by web browser), causing the browser to sometime not being able to utilize full bandwidth available for it. Hence, many a time, if a sprite gets too large, you may want to consider breaking it into 2.

  39. 39

    Mmm, the first point of your article is wrong, even with cached content, the browser still has to make requests for single every resource.

    About maintainability, you just have to be smart. Distribute your graphics in a way that adding new content doesn’t affect the rest and divide your sprites by type, maybe one for layout, one for icons and one for buttons and other widgets.

    And, for the record, Google’s “mega-sprite” it’s only 164×106 pixels :P

  40. 40

    Gregory Raby

    March 26, 2010 7:50 am


    I get your point but I’d rather disagree.

    – The compression argument is surprising to me. Whenever you optimize your imagery correctly, you’ll hardly see any difference with a zipped version. That’s the whole point of compressing.
    – That wouldn’t reduce the http requests. you’re still pointing to different elements – in the same file, yes but still. A great example of that today is when you want to embed specific pages of a pdf.
    – Last point, file maintenance & caching. For any file update, you’ll need to recreat and then replace the whole ZIP file… which all your visitors would need to cache again.

    For buttons, I’d rather use dynamic text overlays, particularly in the case of multilingual sites. For nav bars and various imagery part of the site structure, I’d use sprites (not mega sprites).

  41. 41

    I’ll admit the first time using sprites considerably slowed my work flow. My mouth was full of foulness. If my mother heard the vile I spewed at my computer screen, she’d probably think she failed me as a parent. Yet, after I learned the process of sprites, I found it to be an enjoyable part of my work flow.

    The major benefit to me is organization and consistency throughout the design process. If I am looking at all my sprites at one time, I’m going to catch nuances and flaws in my design.

    I think a lot of the frustration with sprites is that they highlight inefficiencies and gaps in one’s design/implementation process.

  42. 42

    @nkm: well, that is if you didn’t set the cache control of the resources. If caching is set correctly, the browser need not even send a HTTP request for the resources at all. Not that I disagree with you, a lot of websites still don’t set cache control.

  43. 43

    Excellent article, thanks for posting!

  44. 44

    I agree, sprites load much smoother. For example, when you rollover a button that is not a CSS sprite, sometimes you can see the rollover image loading while your cursor hovers over the button. CSS sprites avoid this. Another point, really how big is each sprite? What file sizes are we talking about here 2-5kb? From experience, I very rarely need to change a sprite, at least not in a way that breaks positioning etc. Usually maybe the colour which doesn’t effect the overall css positioning of the sprite.

  45. 45


    thanks for the feedback but perhaps you missed my point.

    1) compression is not the benefit here anymore than with spriting. the benefit is in a single download that is easy to maintain. i am not advocating that all images would be downloaded zipped individually, but instead that all images would be within a single zip that is downloaded once
    2) you would reduce http requests because only the zip file would be downloaded, and all images within that zip would be pulled out of the now cached local copy by the browser
    3) file maintenance and caching argument against zip is identical to the situation with spriting – replace one image and you must re-download the entire sprite (or in my proposal, zip).

    i do agree with buttons as far as text overlay — i always fight tooth and nail against text-within-images unless it’s one or two general logos.

  46. 46

    Jeremy Carlson

    March 26, 2010 9:30 am

    I’m 100% with Lennard…sliding door buttons rock. I try to use them whenever possible. I also don’t agree they look ugly. Plus maintenance is waaay easier.

  47. 47

    Rizqi Djamaluddin

    March 26, 2010 9:33 am

    Good food for thought.

    I usually start off my designs without sprites, and perfect the interface to the point where I know I won’t be doing many more “this needs to be larger” sort of changes. Then I convert to sprites, but only for related elements; almost entirely just for hover effects.

    Larger things that are unrelated to anything else (like large design elements, like headers and such) usually don’t go into my sprites. But the different states of a button, or different pieces of a menu; those do.

  48. 48

    For images?

  49. 49

    ALL in CSS is a big Nuisance.

  50. 50

    This is wrong. First you explained the benefits of using sprites, and then you made some assumptions about the time it takes to create and maintain them.

    Also you said that multiple images affect only the initial load. Exactly. This is when you loose visitors.

    A more appropriate article would explain the pros and cons of using sprites, and let the designers decide what works better for them.

  51. 51

    To true Zack, i do mine all through php’s GD much in the same way you do yours in .net. I collect all nav elements in a folder and build a single image with it. Using sprites for me has significantly helped performance and visually its always far smoother. Whether they are mega sprites or just the different states for each menu item it still holds true to improving performance.

  52. 52

    Satya Prakash

    March 26, 2010 9:48 am

    Internet speed has increased but Js components has also increased and so many other things. and also we should not waste resources we can save. So, sprite is good for saving resources.

    Information about background image and important image is informative.
    Maintenance is an issue but considering visitors experience gain, it is not much an effort.

  53. 53

    “image-based browsers will cache all images”

    Correct me if I’m wrong, but that’s more of a web server setting. I can, for example, make sure that no files are cached by a browser by setting HTTP headers.

    Also, it’s only cached until the Expires date or the Last Modified date (based on your screenshot above), and most shared web hosts don’t set this far enough ahead (usually expires 24 hours).

    With CSS Sprites, you take one big hit for unprimed caches, but if you set it with a far enough Expires date or (Cache-Control max-age) and set Last Modified (or Etags), then primed caches will benefit. These are people who view more than 1 page and people who regularly visit your site (say, once a day).

    I guess what I’m trying to say is that it’s better to use CSS sprites for CSS background images that are used on all of your pages (for example, the site name/logo or RSS feed icon or persistent UI controls like search buttons). I don’t think there can be a solid argument against this; it’s been benchmarked a million times by people who specialize in front-end performance optimization and engineering.

    I like the alternative, out-of-the-box thinking on this article, but you have to understand that many people here, if not most, are just beginners. They’ll read this headline and say, “Oh I better stop using CSS sprites because they’re annoying.”

    There is a lot of nuance in this topic that even experienced web devs will have a hard time grasping.

    So I hope people read my comment: “Keep using CSS Sprites (correctly)!”

  54. 54

    ” Only when we can control what part of an image to show through css, css sprites will start showing their real value.”

    Totally agree on that one.

  55. 55

    No offense, but this article is drivel. No coherent argument against using sprites, other than time spent to update and maintain them, is really coherently communicated.

    I can tell you from experience running high performance sites that browser pipelining and preloading techniques can dramatically increase the user experience, and while there is no set technique, reducing the number of assets always reduces load time – it’s not a web browser problem, it’s an http problem.

    Sprites became standard technique because they’ve been a standard technique for a long time in Web Engineering’s various incarnations. I hope more people will use them, and understand how and when they should be applied.

  56. 56

    Hey Jacob,

    > Creating Sprites takes time
    > Changing Server Settings (.htaccess [if your host allows it, better get a new host if not] http headers) takes time
    > Even though I really like the CNAME idea below, this takes time.

    It’s important to understand that this is on a per server basis. Using multiple domain names, such as,,, etc., allows a web developer to achieve a multiple of the per server connection limit. This works even if all the domain names are CNAMEs to the same IP address.

    As always, it will depend on the site which way you decide to go…

  57. 57

    I agree with Jonathan, most of these points are incoherent or negligible.

    “Browser cache all images” is a nil statement, given it’s highly subjective on a case by case basis, based on the site, and the browser settings.

    Maintaining sprites isn’t difficult. This is what I do when I add a sprite… Resize Canvas > Ctrl+C, Ctrl+V, Ctrl+S. This is how I replace the state of a button. Selection > Delete, Alt+Tab, Selection, Ctrl+C, Alt+Tab, Ctrl+V, Ctrl+S.

    Why exactly is that so difficult?

    Arguing that browsers can now open multiple connections is a straw man argument. Because bandwidth isn’t as big of a bottleneck as the time it takes to establish, open, and close connections. Moving from 2 connections to 6 connections still maintains its slow downs to open and close those connections on a case by case basis. This is an issue with the nature of HTTP.

  58. 58

    Alright, I can’t seem to let a sleeping dog lie. I feel like I have to add to my previous comment.

    Before I do, I want to say that I hope the author (Louis) has no hard feelings for what I’m about to write below. I know Louis, and I’ve had the distinct pleasure of publishing his writings on my own site, Six Revisions. This comment is about the content, not the author (who is, by the way, an awesome dude).

    I’ll go through it point by point.

    “Browsers Cache All Images”
    – That’s not true. So, I’m moving on.

    “Time Spent Slicing a Design Will Increase”
    – If it does, it’s marginal to the benefit.

    “Time Spent Coding and Maintaining Will Increase”
    – It will increase, slightly. Again, not enough to merit NOT using CSS sprites. The time spend coding/maintaining will marginally increase. Also, maintaining it isn’t an issue: You set it and forget it.
    – Additionally, if you’re working with 10 distinct image files instead of just 1, ISN’T that harder to maintain? So in that respect, saying that “maintaining will increase” is invalid and false.

    “Not Everything Should Be a Background”
    – I don’t see how this is an argument against CSS sprites. This is like saying “Using condoms will promote teenagers having sex, so lets not use condoms anymore.” People who don’t know how to use CSS background images continue to do it regardless of the prevalence of CSS sprites or not.

    “Improper Use of Sprites Affects Accessibility”
    – NOT an argument against CSS sprites. Improper use of CSS background images affect accessibility; this is NOT an issue that is isolated or exacerbated by CSS sprites. Improper use of tables also affects web accessibility, that doesn’t mean you should completely stop using tables (they’re semantic and actually great for screen reader accessibility for table data, especially when using proper markup like table headings).

    “What About HTTP Requests?”
    – That’s true, there are more things to worry about than just HTTP requests. Again, how is this an argument against CSS Sprites? Also, note that 6 out of the 22 of the criteria shown in the screenshot (Yahoo’s Best Practices for Speeding Up a Websites) directly relate to or lead to reducing HTTP requests.

    “What About Sprite Generators?”
    – Don’t use them. Whether you’re for or against CSS sprites, it’s always better to make a sprite yourself.

    “Focus Should be on Multiple Performance Issues”
    – Not an argument against CSS Sprites, again. Obviously, you shouldn’t focus on just CSS Sprites… I don’t know 1 professional developer that says, “Oh hey guys, I can’t work on anything else because I’m making this CSS Sprite right now, kthanx!” or “Man, I really need to decide: CSS Sprites or remove duplicate JavaScript and CSS.” It’s not either/or…

    My thoughts:
    – You should use a combination of both CSS background sprites and regular background images. The choice is situational and based on performance and feasibility.
    – You should use CSS background sprites for CSS images that appear throughout all of your website.
    – CSS background sprites truly improves user experience, it makes the site feel like it’s more responsive. Have you ever experienced a navigation button or user interface element that momentarily flickers before revealing the hover state? That’s because they don’t use CSS sprites and it has to download the hover state.
    – CSS background sprites is great for reoccurring UI elements, as it improves primed cache response times.
    – Don’t include one-time-use CSS background images on your CSS sprite because this will increase the file size of your CSS sprite.
    – CSS Sprites is best practice for front-end performance, based on plenty of studies and benchmarks (e.g. real data and experiments) conducted by dudes that have like three Ph. D’s and do nothing more than make websites go really fast (e.g. really smart dudes that know what they’re doing).
    – Don’t include CSS background images that are rarely being accessed in your CSS sprite.
    – Using CSS Sprites IS NOT difficult (as this article implies)
    – Using CSS Sprites DOES NOT affect web accessibility more than a regular CSS background image, as the article tries to imply.
    – Using CSS Sprites doesn’t take a lot of time.
    – The extra time that it does take you, you’ll be better off in the long run in terms of maintenance (less files to manage and keep track of and version). For example, say your theme changes from red to green, you’ll have to change multiple PSDs (or whatever graphics editor you use) and resave all of them one by one! Then you have to manage multiple versions of your CSS background images. OUCH!

    My $0.02

  59. 59

    I don’t think you understood the point of my comment (or maybe I’m not understanding your reply to my comment). I was highlighting the fact that the argument used, which was, “*ALL* web browsers cache images” is not true because caching doesn’t depend on the web browser, it depends on the web server serving the files. Why would I set HTTP headers of static files to not cache? Yes it takes time to do this (like 60 seconds, ouch, that’s a lot of time that I can be spending doing something else), but why would I do that? That’s not the point of my comment.

  60. 60

    daniel cordell

    March 26, 2010 12:35 pm

    Ah, the opening of the last couple articles (by different authors).

  61. 61

    Justin Carroll

    March 26, 2010 12:53 pm

    Screw the user and forget the statistics, I use them because they’re easier on my development process. And seriously, generators? Honestly, will nerds in this industry please stop making generators, they’re pointless and they enable shitty designers/developers to cut corners. I guess it’s a rant-Friday. :)

  62. 62

    All the time…check this out though I haven’t fully tested my button out on all browsers, I have on the most recent (FF, Safari, IE, etc.) and it works great. Only one image needed and fully expandable. On FF it has rounded corners and when the rest of the browsers get with it, so will they. I haven’t checked to see if anyone else has already created this technique, but feel free to use it and let me know your sites!

    And yes, these types of buttons are amazing for multilingual sites.

  63. 63

    I’ve used this to generate my sprites in my last couple of projects.

    It costs a couple of dollars, but saved me a lot of time stitching and working out CSS and background positions. Even handled the gzipping too.

  64. 64

    Jacob, I think I was implying in the article that the browser and the server will cache images using default settings, which would occur for most visitors. Maybe I’ll adjust the wording, so it’s not so dogmatic about that.

  65. 65

    Wow, that’s a lot of info, and I appreciate your taking the time to provide this feeback, Jacob. (And for the record, I think Jacob is an awesome dude too, so this doesn’t mean we hate eachother!) But I have to say, Jacob, you’ve misrepresented what I’ve said in the article.

    My article does not constitute an argument against using sprites. The title of the article is “Useful Technique or Potential Nuisance”, which implies it will cover both sides, but (admittedly) with a bias towards the “con” side.

    Yes, I could have written a straightforward, no-controversy article where I suppress my own opinion and write a boring piece where everyone says “nice roundup of pros and cons!” But I hate those articles, so I wrote this instead.

    Some of the headings that you pointed to and said “this is not an argument against using sprites” was misrepresenting what I said, because those headings were not necessarily saying that sprites were wrong, but discussing the issue.

    What’s interesting is that I actually did tone down the article quite a bit and tried to make it more “pro and con”. That obviously was a waste of time! :)

    Anyways, thanks for the feedback, Jacob. I still think you’re an “awesome dude”, and one of the best designers I (electronically) know.

  66. 66

    I’m sorry, but the question you’re asking is just plain stupid. Here are a few reasons why:

    – If you know what you’re doing, sprites don’t take any more time to create and implement than separate images.
    – Not everybody in the world has broadband.
    – The reduction in requests to the server is not just for the user’s benefit, it also greatly reduces server load and can significantly reduce bandwidth consumption from eliminating 2 chunks of header information per image request.

    The list goes on and on. You should remove this article and save yourself some embarrassment.

  67. 67

    LOL! That is too funny…

  68. 68

    I would love to see an article discussing this technique with PHP, because I think Zack’s method is pointless if it requires the use of What percentage of developers are using Maybe only those working in-house. What percentage of freelance developers are using it? Very very few, I would guess.

    And remember that any solution needs to be practical and easy-to-use, otherwise nobody will use it. But this is definitely something worth looking into, thanks for pointing it out, guys.

  69. 69


    #1 – I wasn’t “contradicting” myself when discussing caching. I was stating both sides. Please read the last paragraph which asks readers to explain whether they feel CSS “mega” sprites are worth it. So obviously, I’m not necessarily being overly-dogmatic, but simply showing some bias in favor of my opinion, while showing some of the opposing arguments.

    #2 – The stuff I said about maintenance is very true in many circumstances. See one of my comments below in response to Jacob, where I quote from a .net magazine article.

    #3 – The last few issues you discussed have to do with button states. In the article I did not discourage the use of sprites in buttons. Button sprites should *always* be used. But if you use “decorative” sprites for non-linked images, you lose the alt text. A background image on a non-linked element does not have ALT or TITLE text. Again, this is for non-linked elements. I strongly encourage the use of Sprites for buttons, but I think sprites can be overly troublesome when used in the “mega” format.

  70. 70

    Good points, Chris. I think this comment adds some good info to the pros and cons. Thanks.

  71. 71

    >But if you use “decorative” sprites for non-linked images, you lose the alt text.

    For decorative images, you don’t need alt text or title. It’s decorative, not content. Therefore this point of yours is moot.

  72. 72

    I disagree. I found it cleaner to work and easy to maintain, plus the benefists that improve perfomance in many ways.

    CSS sprites are a good practice.

  73. 73

    Andy, you’re missing the point here: I agree that decorative images don’t need (and shouldn’t have) alt or title text.

    The article says that if a user decides to use the sprite method for important content (that is, content that’s not supposed to be decorative), then that content would not have the ability to be read by screen readers, and thus would not be accessible. And that’s for non-linked images. So the point still stands: Promoting the overuse of sprites could cause beginning developers to make important, non-linked content on their websites inaccessible. I probably should have been more clear in the article about the fact that I was talking about non-linked elements.

  74. 74

    Just for the record, in the article I was referring to a single button that is not part of a navigation bar (for example, a call-to-action button) that would have a set width. That’s why I said “single button”, but maybe I could have made that more clear.

  75. 75

    You’re missing my point. This is critique on the bad parts of the article, not the article as a whole.

    “The article says that if a user decides to use the sprite method for important content (that is, content that’s not supposed to be decorative), then that content would not have the ability to be read by screen readers, and thus would not be accessible.”

    And again, this is not an issue relating to CSS sprites, but background images in general.

  76. 76

    “…internet speeds are higher on average today than they were when this technique was first expounded upon in 2003-2004…”

    Maybe in Toronto, Louis. Not here. So I have to pick you up on that inaccurate generalization. 512 was what we had here in 2003 and 512 is what we have now. Despite recent gov’t promises, I expect that to last for at least 5-10 years. Rural telecoms infrastructure sucks.

    The point that I’m making is that performance still really matters to the user experience for a significant minority of people. A little extra loading time on a background image is moot, but a delay in a hover/focus effect because another image has to be called is noticeable, looks odd, and it’s avoidable thanks to sprites.

    I really don’t like knocking someone else’s work, but I have to reluctantly agree with the numerous comments that assert that this article is not up to standard.

  77. 77

    Agreed, so I think there’s no problem here. The article says exactly what you’re saying, so I don’t know what you mean by “bad parts of the article”.

  78. 78

    Marc, where is “here”? My statement in the article was not about any specific areas, but was saying that generally speaking internet speeds have increased. Just because they haven’t in one country, doesn’t make that statement false.

    And I think you need to go back and read the article (because I don’t think you did read it all). The article specifically says that using sprites for button rollover states is perfectly acceptable, but extending the technique of sprites to the “mega” method could potentially cause problems in a number of areas. (Note the use of the word “potential” in the title).

    See also one of my previous comments that quotes from a .net magazine article that states similar concerns about overusing sprites.

    Marc, nothing in web development is universal. No article could possibly be 100% true for every circumstance (or every developer, or every location, etc). But I think these are legitimate concerns that every developer should consider before using the “mega” sprite method. The article is not a knock against button sprites, it’s a knock against the use of “mega” sprites.

  79. 79

    Article Playground

    March 26, 2010 10:53 pm

    Thank you so much for all the useful information you always provide and share freely with us. So thankful for your site and always able to grab free WordPress themes. Much thanks & support :)

  80. 80

    I agree, sprites are good for some things but, they have inappropriate usage as well. I usually combine my buttons images in one sprite (I want to mention that they are with auto width). But using sprites for background on elements with auto height and width can cause unforeseeable consequences. Also with technologies like CSS3 there will be less need for using images at all.

    I mentioned that I use sprites for the different states of one button – the reason behind is that I really hate when I access some fancy looking site, and try to use its fancy navigation, and then boom! On hover elements are vanishing. It makes it look really unprofessional.

  81. 81

    Marc are you just trolling or you really read the whole article?

  82. 82

    I think that sprites are good idea in some cases, making backgrounds, navigation menus, contact forms, buttons, etc… but when the markup is not longer readable I know that sprites aren’t a better option.

    Great Article.

  83. 83

    We just had sprites put in for the rollovers on Project Bubble ( because before there was a gap of a few milliseconds until the rollover loaded, so a guy called Michal Kopanski kindly made sprites for us. The sprites were all of the icons in all their states. I’ve been really pleased with the result so I’m all for sprites.

  84. 84

    Sorry mate…

    Well researched and documented article but you’re missing a BIG factor.

    Let’s say you’re using 3 images now for one button – normal, hover and active – the hover and active images won’t be preloaded…

    So when a user hovers over the button there’s a slight gap where the button disappears because the image hasn’t loaded yet. Looks really amateurish.

    Use a sprite and all three states are preloaded without any fancy preloading techniques.

    I think you’re trying to reinvent the wheel here (which by the way I support and commend) but coming out with a square.

  85. 85

    It baffles me how often you see this :hover loading flicker happen, even in very professional websites. And the solution is so simple! ;
    Just create a style with _all_ the :hover background-images assigned to it (yes, this works fine) and put that style on an empty div at the top of your page, and position it out of the visible area one way or another (but do not make it invisible as some browser will not cache bg-images of hidden elements). There you go: easy preloading of images, no sprites needed for that.

  86. 86

    I tried to carry away some good points from this article but the only one I could think of is:

    If you know what you’re doing use CSS sprites. If the process of creating and mantaining CSS sprites is too hard for you then don’t use them.

    There is no other valid reason to NOT use CSS sprites. Especially working with high-traffic sites that get thousands upon thousands of hits per day. It just doesn’t make sense for the user and your web server to deal with extra file sizes, extra bandwidth, and extra CPU cycles when it doesn’t have to.

  87. 87

    Yes, I read your article in full, Louis. I even printed it out to study at my leisure before commenting. So I am fully appreciative of what it states, thank you. “Here” refers to the United Kingdom.

  88. 88

    Jamie, nowhere in the article did I discourage the use of button sprites. That’s not what the article is about. The article is about the use of “mega” sprites, referring to the practice of placing all background images (not just buttons) into a single sprite. Here is a quote from my introduction:

    In this article, I’m going to discuss some of the pros and cons of using CSS sprites, focusing particularly on the use of “mega” sprites, and why such use of sprites could in many cases be a waste of time.

    And in my conclusion, I specifically targeted the problems with “mega” sprites, not button sprites, which I wholeheartedly support 100%.

  89. 89

    António Manuel Cardoso

    March 27, 2010 11:54 am

    It’s a great article. We already use in It’s great for speed page

  90. 90

    Check out “sliding doors” on alistapart

  91. 91

    The most important advantage of sprites in my eyes, is when using it for hover behaviour on buttons/menus – There’s no loading time for the second and third state.

    When you use separate images, there’s an annoying flash if the second image is not loaded properly.

  92. 92

    Just make them preload: see my reply a little earlier; nr 45

  93. 93

    Its a matter of purpose i think. Big sites like Google, Amazon, Facebook can save a lot of load on their servers by just saving a few kb per visitor (remember they get millions/billions of visitors) but unless your site traffic is big or you are having performance/bandwidth issues (like running out of bandwith with your current hosting package) then sprites (especially mega ones) are not worth the effort unless you know for sure you will never change the site again in the near future. Compressing the “content” images in the page to as much as possible (so they still look good) will make the biggest difference i find. I have actually also just uncompressed and separated all my javascript and css as well because it was too much effort to maintain them in one file. Every little css change was a pain in the backside, for what, 5kb…. my site has 10,000 visits a month, most of them are on fast broadband (thanks Google Analitics) so its not worth it. A content image on my home page was 38kb dropping that to 12kb saved much more!

    So for me if the site gets huge traffic sprites are good – or if you dont plan on any re-jigging they are also great, for average jo, dont bother. Thats my (in-experianced) opinion.

  94. 94

    Michael Lomas

    March 28, 2010 9:00 am

    I tend to save sprite use for button states as well mainly to avoid the nasty flash upon loading a given state. It also makes development life easier by just shifting the background position rather than creating and referencing more files in the CSS.

    I’m less inclined to use a single sprite file for every image, the various background positions tend to get complex, especially if you change the size of an image in that sprite later down the line.

    If we take the semantic approach does it make some sense that a button and its states should be one sprite file and that other elements should have their own individual files?

  95. 95

    Gavin Roberts

    March 28, 2010 9:55 am

    Something I assumed the browser could handle nicely was the ability to use the same sprite a number of times.

    Instead, if I reference a sprite in one css file and on the same page, reference it again in a different css file, it appears to download the image twice.

    More annoyingly, is that when I first started using sprites, each of the elements that used it, had it’s own background-image declaration and it appeared to create a http request for each one instead of doing the first and then using the cached image for the rest.

    Now I have to declare a single style at the very top that contains every single selector that would use the sprite so it only does it once per css file.

    Anyone else noticed this or have I completely misunderstood the whole concept?

  96. 96

    Simone Susini

    March 28, 2010 4:16 pm

    Have you never heard about Data-URIs? It’s a great way to get fewer http request embedding encoded images directly in the css.
    If you use it with an automatic asset manager ( like Jammit for rails ) you get easy maintainability too.

    To see an example you can check the css of

  97. 97


    You bring up some interesting test cases. I really can’t say for sure what the browser does in those situations. I find it odd, however, that you would have two different CSS files referencing the same sprite. That tells me that the way you organize your CSS is wrong. I would never allow two different CSS file to reference the same sprite. So that should resolve that first issue — but it would be interesting to find out if what you’re saying is true.

    As far as the second issue you mentioned, I think you’re wrong. The sprite should be cached, and should only result in one http request. However, if you’re using Internet Explorer and you have your browser settings set to “always look for new versions of a web page”, then I believe you would see multiple http requests. Of course, if you’re talking about using multiple CSS files, then that might again be the cause of the problem. It’s definitely something worth testing to know for sure, but I personally don’t care all that much because I would never reference the same image from two different CSS files. It seems counter-productive to organize your CSS that way.

  98. 98

    I find it interesting how many people have commented on this article under the assumption that I’m advocating never using CSS sprites. Maybe the title of the article was a bit too controversial, I don’t know.

    To clarify this matter, and to provide a further response to Jacob’s comments above, the following are direct quotes from the above article:

    And just to be clear, as already mentioned, I’m not saying sprites should never be used; I’m saying they should not be overused to attain limited benefits.

    If you feel that sprite maintenance won’t be an issue for you, then the best choice may be to use the mega sprite method.

    So, while CSS sprites in and of themselves are not wrong, and do not cause accessibility problems (in fact, when used correctly, they improve accessibility), the over-promotion of sprites without clearly identifying drawbacks and correct use could hinder the progress the web has made in areas of accessibility and productivity.

    It should also be noted that one study conducted showed that 40-60% of daily website visitors come with an empty browser cache. Is this enough to suggest that mega sprites should be used in all circumstances? Possibly. Especially when you consider how important a user’s first visit to a website is.

    Please don’t misinterpret anything that I’ve said here. Many top bloggers and developers have for years extolled the benefits of using sprites, and in recent years taken those suggestions further in promoting the use of mega sprites — so those opinions should be taken seriously.

    So obviously I am not promoting the idea that CSS sprites should never be used. I use them all the time, just not in the “mega” format. I just think developers should think about what they do, and not just do things for the sake of superficially following the example of well-known trendy developers.

    Also, keep in mind that Steve Souders’ book recommending that we do whatever we can to save HTTP requests is a book aimed at “front-end engineers” who mostly work on large-scale applications. I think that’s even more reason for “Joe Blow Freelancer” to take Souders’ advice with a grain of salt and consider his own circumstances to see whether or not using “mega” sprites would really make all that much of a difference in overall performance.

  99. 99

    CSS is Da Bomb dude, always has been, always will.


  100. 100

    Martin Chaov

    March 28, 2010 8:51 pm

    Guys, the browsers cache is not unlimited :) Older files are deleted in order to save new ones. Take this into consideration.

  101. 101

    All, please read the comment by Jacob Gube. Spot on.

  102. 102


  103. 103

    What else do you recommend, Professor?

  104. 104
  105. 105


    Thanks for posting your response. I have a few comments on what you said:

    About caching: The items will be cached whether they’re sprites or not, so the performance gain (assuming default cache settings) will only be on the initial page load. Yes, as you said, the sprite will be cached, but that will also occur if you have multiple images.

    About slicing a design: What you said here supports my statements in this article. You basically said that the sprite will be in a separate layered PSD. That means, instead of just cutting your images from your website mockup, you’ll first have to create a website mockup, then after you decide which images are the “decorative backgrounds”, you will place those in a new layered PSD. Remember, this section was not about maintenence (that’s the next section). This was about “creation” of the PSDs. Creating a separate, editable sprite, needs to be done from your original mockup, so it’s a 2nd process in addition to the original. Do you understand my point? Am I misunderstanding yours? Please elaborate, if necessary, because it seems your discussion of this just confirmed what I had theorized.

    About Maintenance: I think you made some excellent points here, and any tool that can help developers maintain sprites would be great, if in fact the benefits are enough to warrant their use.

    About backgrounds: To answer your question: A beginner who doesn’t understand the importance of accessibility and semantics might place a UI element in an img tag, or vice versa. Developers are always talking about the importance of keeping backgrounds as decorations, so your assumption that nobody would ever do this is just wrong.

    About speed: You claim there are other benefits to sprites. What other benefits are there? From what I can see, outside of responsive hover states, the only benefit is speed.

    I appreciate your feedback, and I encourage all developers to think like Ryan and try to do what’s best for them. Don’t just believe what I’ve said in this article. Try out sprites for yourself and see if you can’t make them work for your projects.

  106. 106

    Cre8ive Commando

    March 29, 2010 3:29 pm

    Personally I think that CSS Sprites are not too time consuming to create and are great when used correctly. Rather than having one huge mega-sprite I would opt for creating a few smaller sprites e.g. one for icons, one for web template decorations etc (This will just make them a bit easier to manage) :-)

  107. 107

    It’s another case of using the right tool for the job. CSS sprites, like any tool, can be abused, but applied tastefully they can make a significant improvement.

    I personally find them easier to maintain, in many cases, because opening a single file in Photoshop gives me all my UI elements, making it trivial to apply touch-ups and replicate them across the entire theme. The trick is try and avoid putting dissimilar objects in the same image. If you’re finding maintenance to be a chore, maybe you should move the most frequently updated pieces to their own file(s). Bear in mind, every time you make a change, all browsers have to download the new file. If 90% of that sprite map stays the same, you’re wasting 90% of the bandwidth – the browser can’t tell which parts of the file have changed, it has to pull the whole thing down.

  108. 108

    On top of it: depending on your configuration the browser checks if an image in the cache must be updated or not. That requires traffic and time too.

  109. 109

    Sprites I use only for navigation. Thus far I haven’t actually needed a mega sprite. Sliding doors rock too.

  110. 110

    You mean like how sprites worked on the old nintendo/genesis sytems where every visual element in Mario Brothers lived in a single image.

    I’m still shocked how few people have come to this realization. And depressed that the w3c & browser makers haven’t started working on it.

  111. 111

    Sprites are a nuisance and certainly add an overhead in terms of performance.

    They also don’t work on things like BlackBerry browser for example.

    I have been trying to avoid them wherever possible these days through use of CSS3 properties as an alternative. This is the only area (for now) where I am seeing CSS3 being useful.

    I have certainly had an issue with maintaining CSS sprites in the past.

  112. 112

    Avoid text in your images
    utilise sprite concept for icons primarily
    set up states on the horizontal of the file allows for future expansion.

  113. 113

    Carolyn King

    March 30, 2010 3:27 pm

    I’ve found using sprites actually reduces maintenance if your workflow is logical. I completely agree with Andy (comment 51). I create sprite source files by dragging graphics from the mock-ups into a new layout file, which becomes the sprite master file that can be exported as a jpeg/gif/png. Changing a graphic is easy, as the sprite master file always matches the final jpeg. You often need to add new graphics anyway, as the original mock-ups rarely include all the graphics you need. And having a sprite master file means you don’t have to remember which layer of which mock-up a graphic appears on.

    I usually create two or three medium-sized sprites rather than one mega sprite, so I can combine similar image types (eg jpeg vs gif/png, depending on transparency, tonal/colour range etc) or to keep similar objects together (eg navbar, buttons, icons, panel backgrounds). Keeping images with a similar colour palette together can reduce the file size quite a bit.

    As I’ve only discovered the benefits of using sprites recently, I’m even thinking of going back and editing a couple of my earlier sites to include sprites, to improve display speed and manageability! I’m sure the automated sprite management tools mentioned by others would be useful for bigger projects.

    I only use sprites for style/navigation elements – inline images are best for content-based graphics, and should be in a separate folder anyway (they usually are if you’re using a CMS, so the site owner can maintain them).

  114. 114


    What is difficult about maintaining a sprite is not necessarily the changing of the image file (that’s only part of it, if any of it). The adjusting of the background position in the CSS for any new elements in the sprite, or for any resized elements in the sprite is probably the main factor in maintenance.

    In the article, I brought up the maintenance issue as a *possible* complication, depending on circumstances. Notice that in that same section, there’s a red sub-heading called “Do Sprites Really Require Maintenance?” In that section, I stated that I wholeheartedly support the use of mega sprites if the developer feels the maintenance issue is a trivial matter.

    Why are a few commenters on here acting as if I am disowning the concept of sprites? The title of the article asks a question; and each section in the article brings up some *possible* problems with the sprite method. I was very careful about that, and it’s a little disappointing that a few people have misrepresented what I’ve said.

    Nonetheless, I thank you for your thoughts, and appreciate you taking the time to give some feedback.

  115. 115

    mike foskett

    March 31, 2010 3:10 am

    I was under the impression that data uri image techniques make CSS sprites obsolete except to legacy browsers IEv7-.
    There a simple image fall-back suffices, or provide a separate CSS.
    Admittedly there’s a 30% file size hike, which may be countered by serving gzipped or deflated.

  116. 116

    It is also possible to use sprites as backgrounds of IMG elements (i.e., a clear.gif). That way you benefit from the ALT text when the image is content.

    Another technique is to use the sprite itself as a IMG that you position differently:

  117. 117

    Omer Greenwald

    March 31, 2010 11:30 am

    Thanks for an interesting post. Up until now I have preferred using CSS sprites for images that appear in every page in my blog instead of letting them be loaded separately but with the advantage of alt and title attributes. I assume that with the proper cache settings for those images I can slice the sprite again and it won’t slow down performance.

  118. 118

    We implemented this on our Intranet and reduced our HTTP requests by 95%. page loads super fast now! Excellent thing to do!

  119. 119

    Great article. I make separate PSDs for all my sprites, and arrange my sprites in the order in which they’re accessed. Works well for my purposes.

  120. 120

    I never tried to use mega-sprites, just separate sprites for different elements.

  121. 121

    useful points……….thanks

  122. 122

    The reason some people don’t like sprites is because sprites is actually a “hack”. The only reason they are used are because we have to adjust to the browsers faults and the W3C faults.

    Sure in some cases you might always want to use sprites, but in most cases you don’t (in a perfect world).

    What should exist is a package. In that package you had all the files you wanted to send to the user (all icons for example). And image corners and so on should be defined in CSS from only one image and not by using a lot of corner images and so on.

    So yes, sprites is often needed today for performance, but they are still hacks and shouldn’t be needed if browsers and web standards did their job.

  123. 123

    its not a hack or even responsibility of W3C or browsers its how Http protocol works

  124. 124

    One problem I’ve come across with using sprites for menu buttons is that there are a number of people, not a large group but not insignificant, who surf with background images turned off. The standard technique for creating sprites buttons is to indent the text on a link off the page. This is fine is the user has CSS turned off, as the text will appear, but if the user has turned off background images but left CSS otherwise untouched they will see nothing but a blank space.

  125. 125

    Stanislaw Osinski

    April 4, 2010 5:03 am

    To avoid the CSS sprites maintenance headache, you can use SmartSprites:

    SmartSprites parses special directives you can insert into your original CSS to mark individual images to be turned into sprites. It then builds sprite images from the collected images and automatically inserts the required CSS properties into your style sheet, so that the sprites are used instead of the individual images.

  126. 126
  127. 127

    James, very clever use of “outline”. :)
    The buttons look really nice.

  128. 128

    Kevin Graves

    April 6, 2010 10:42 am

    An article that further explains the benefits of using CSS sprites and to some degree a different approach to Lazaris’ ideas about the benefits of using sprites

  129. 129

    Elizabeth Kaylene

    April 6, 2010 11:01 am

    You don’t have to list every single element you want to reset in your CSS the way you did:

    html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, sub, sup, tt, var, b, u, i, center, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td {margin: 0; padding: 0; border: 0; outline: 0; font-size: 100%; vertical-align: baseline; background: transparent;}

    Instead, you can use

    * { margin: 0; padding: 0; }

    etc, etc. (:

    Edit: Oh, never mind, I see what you were doing there. Ignore me!

  130. 130

    I agree with most points of this article, sprites can seriously hamper workflow with clients that are prone to doing big changes with layouts, etc (which in my experience is quite common).

    They have some benefit, but I think that benefit is somewhat overrated.

    I build a lot of designs that incorporate transparent images (later png fixed for Ie6), and repeating images, and I often use jpg, gif or png depending on which looks best with the smallest file size… how to deal with those issues using mega sprites?

    Also, when a new visitor enters a site (from any landing page) they may not need to load every single image for every single page in one giant mega sprite, they may only need 5% of those images… so how does that save on bandwidth? Or should every page/template have it’s own mega sprite?

  131. 131

    Cool idea!

  132. 132

    Very cool buttons!

  133. 133

    @Greg Givan:
    LOL. Someone is speaking the truth, here. :D

  134. 134

    Thanks Louis for such a Great article,

    Although am not stand for all what you say, but it’s just Inspiring to listen to someone with a new point of view, instead of just saying all the old things and doing everything just like someone did before.

  135. 135

    My approach is to have a vertically tiled sheet and a horizontally tiled sheet. Omnigraffle is great because it always shows you up the top the pixel location of each item you have selected, then it’s just a matter of copying and pasting those values into the stylesheet and adding a ‘-‘ to the front.

  136. 136

    I recently encountered an interesting issue concerning mega sprites as well… apparently mobile Safari simply won’t render background images larger than 15,000 px in width (not sure what the height limit is). The same mega sprites are also causing scrolling to be extremely slow in Chrome/Mac (which I’m assuming is a bug that will be fixed). Beware the mega sprite!

  137. 137

    CSS Sprites can be a huge difference when it comes to mobile webpages where every HTTP request counts a lot and having a 10 kb website is something you can be proud of. (Imagine that you can open your website in seconds even if you have lots of menus and stylings) Those images would add a lot of http requests and in mobile networks the pings isn’t great so when it comes to getting the content in the lowest http requests css sprites are a must unless you code totally in HTML5.

    Opera and Safari Mobile do support HTML5 so it’s the next step we have to take.

  138. 138

    I am using 30 individual images in my navbar the total size of which is 67.6kb. I used the Project Fondue SCC sprite generator to generate a single image sprite will all the 30 images combined and to my surprise the size of this single image was 135kb ! double the size of the individual images.

  139. 139

    Doesn’t matter if it’s bigger, the important thing is it is a single image. That’s the benefit of using a sprite, that there is only one HTTP request. File size is not as much of a factor if there is only one request instead of 30 requests. Although I do think the image you’re talking about could be further optimized. Nonetheless, a single image is much better than 30.

    For nav images, I say go with sprites, but for other backgrounds, you’ll have to weigh all the options.

  140. 140

    @ Your article has been working faster than my coffee!

  141. 141

    Nice Topic ,Can I use CSS sprit for Base64 format ??????

  142. 142

    For me the main problem using CSS sprites concerns accessibility. Functional images (i.e. a print icon opening the print function, a play button, etc.) or images providing information (i.e. pdf icons within a link with alt text PDF to convey information to screen readers) should never be other than inline images. When you turn off CSS or when you use High contrast facilities as provided by Windows or Mac operating system, your images or the alt text will not be displayed and therefore the user will not be able to fully use your website. You can try to use some tricks to display a text instead when CSS are not active or try to detect if the user is in high contrast but does it worth?
    You may argue that for functional or information use it is better to use simple text instead of images but this is another debate.
    I would say: If images stays on the browser cache, CSS sprites for repeating decorative images, inline images for functional or information images.

  143. 143

    E20-001 Testking

    April 22, 2011 9:45 pm

    File size is not as much of a factor if there is only one request instead of 30 requests. Although I do think the image you’re talking about could be further optimized.

  144. 144

    It was good and I got to know few good things.
    I have also created a CSS sprite for my site at: Here, you can see an image on top I have used this CSS sprite as painting.

    One can move cursor over this image and it will turn into colored picture.

  145. 145

    I find it interesting that people are taking about mega sprites that have 10 or maybe 30 images. That doesn’t seem particularly “mega” to me. The mega sprite file I just inherited has 100 images! And those are just buttons. (Yes, every button is made with embedded text.) Not only that, but this file was created originally for a different project so 90 of those buttons aren’t used by our application. And the original PSD file was never delivered by the design firm they used, just the final pngs and gifs.

    Which leads to my point: using mega sprites properly requires discipline and my experience is that software developed by large corporations is rarely developed with that kind of discipline.They are too siloed and personnel turns off too much.

    P.S. Yes, I’ll be reorganizing things to be easier to develop and maintain.

  146. 146

    “turns off” should be “turns over”

  147. 147

    Just adding a little to the mix…

    A site that I’m currently working on contains an considerable number of images, both large backgrounds and small, fiddly foreground pieces. I spent a lot of time working out how best to fit all of the images into the minimal number of sprites, and was pretty happy with the solution (considerable reductions in both HTTP requests and file sizes) until I came to introduce Javascript components (‘Stock’ features like Scrollable and Slides) to the page.

    The sprites that I’ve created are very large. One in particular is 9800px by 550px. Handling this image, while trying to animate content with JS, is causing my browser (Chrome) to slow by an uncomfortable amount.

    So it looks like I’m going to go backward a little, and find a balance between using sprites, while keeping the size of the sprites of a size that my browser can manage. Trickier to maintain though, by quite a way. The solution might run along the lines of “Three backgrounds in this file”, “Four backgrounds in this one”, “A few small images in this one”, and so on, until I can strike the balance that I’m looking for, which in the age of the semantic web feels a little disorganised.

    I suspect I’m on the larger end of the spectrum with an image that measures almost 10,000 pixels across, but even so I thought I’d post a comment because page-responsiveness is something that I didn’t anticipate having to deal with when I set a course for image sprites.

  148. 148

    “Without sprites, users see a gross flicker when hovering over the button for the first time”?

    No. That only happens if you are coding your buttons wrong. Always preload your button or slideshow images. Do it with the right way with javascript preloading or the easy way with a zero height zero width div of hidden html image tags. Right way or wrong way, your rollover images shouldn’t need sprites to prevent flickering. If you need sprites to prevent flickering then you are coding your image buttons wrong.

    The only reason to use sprites is to cut down on server hits. But most websites don’t get millions of hits and won’t see much benefit. It’s an argument about minutia and nanoseconds like using echo vs print in php. Also sprites take time and experience to build. Time and experience cost money and they make it harder to train new coders. These are serious concerns for an organization.

    The whole reason we started using css was to cut down on the time us coders spend on minutia like cutting up images into tables. Sprites are cool, but move in the opposite direction from this progress. If this was really a problem, the html and images would be build as a zip file on the server and sent to the web browser as one file. This is a non-problem.

  149. 149

    If you are on Mac you can use Sprite Master Web to generate your css-sprites easily. It available on the Mac App Store

  150. 150

    Good overview on the area.

    I would take point with the following: “ the future, as internet connection speeds increase and newer browser versions make performance improvements, the benefits that come from using mega sprites could become almost irrelevant.”

    This is not really true. The speed to download a document requested is a product of latency to the server – not bandwidth. 100meg, 10meg or 1meg – you’ll download a document at roughly the same speed.

    If the document is very large in size.. then and only then does bandwidth come into play.

  151. 151

    Mike Gifford

    June 29, 2012 6:54 am

    Good article and for performance reasons I’d definitely like to be using more sprites. This does pose accessibility challenges, as often these elements convey meaning (even little things like email links). However, I do think something like this can work:

    Email links icon

    Where the image is added with the class associated with the span & the text description is hidden by the div’s class.

  152. 152

    two points:

    first, 6 simultaneous HTTP requests is NOTHING. I routinely see pages with hundreds of elements; add any significant latency, and that spells slow loading.

    second, sprites as I have seen them used to date are NOT ACCESSIBLE to non-sighted users, since they contain no text content that’s available to a screen reader. (Try it.) While (as my first point implies) I’d love to continue to use sprites, I have to code accessible pages both as a matter of employment requirement and conscience, and I’ve yet to find a way to make sprites work for that.

  153. 153

    You can use sprites with no accessibility issues, i.e.

  154. 154

    Fernando Franco

    April 15, 2013 9:35 am

    Good article my friend, but pointless, mega sprites are the best way to go!


↑ Back to top