CSS sprites demystified

I must confess that I love to embrace every new CSS technique that comes on my way. But when it comes to CSS sprites, I have to say that it was quite disappointing to find out that this technique poses more problems than it solves. The first problem concerns the vertical offset of the y-axis of the background image positioning. Since sprites are different, we have to deal with new calculations for every new image. Generally, sprites are splitted into rows. Each row has a different height depending on the height of the image contained inside that very row. What's more, there's also a vertical gap between rows that must to be taken into account. So calculations vary from sprite to sprite and there's no universal ratio that allows us to perform this task quite automatically. If things can be simple for a 120 x 100 pixels sprite, where each row is 20 pixels high, things get more complicated when you have to deal with sprites having odd measures.

What happens if we have to change sprites? New calculations have to be made, and this implies more time spent with those calculations. It's true that CSS sprites reduce the loading of a web page, but it's also true that this benefit is surely relevant only on sites with an heavy burden of assets to be displayed or with a lot of traffic. On medium or small web sites, this effect is almost irrelevant. So I don't think that CSS sprites are the new holy grail for saving bandwidth or decrease loading times. The truth, on the contrary, lies elsewhere, for example in a correct server configuration, in a proper resource compression and, finally, in a fast web server. Remember: it's always a matter of hardware, not software.

Leave a Reply

Note: Only a member of this blog may post a comment.