Thursday, April 26th, 2007

Faster Page Loads With Image Concatenation

Category: CSS

Matthew Batchelder has been looking at the impact of latency on web applications with respect to downloading lots of images as icons, based on thoughts he heard from Zimbra when they presented at The Ajax Experience.

His piece on Faster Page Loads With Image Concatenation goes into why and how:

For complex web apps, the quantity and resulting latency of icons and images used can greatly impact page load times…and developers, in most cases, generally try to reduce page load time with a sweet web app rather than increase it.

To reduce latency in my apps, I use Image Concatenation! Coupled with a bit of CSS magic, performance improves and life is great.

He also discusses using CSS to handle inactive icons (instead of duplicate images):

  1. #sidebar img.icon{
  2.         filter:alpha(opacity=50);
  3.         -moz-opacity: 0.5;
  4.         opacity: 0.5;
  5. }
  7. #sidebar img.icon:hover{
  8.         filter:alpha(opacity=100);
  9.         -moz-opacity:1.0;
  10.         opacity:1.0;
  11. }

Posted by Dion Almaer at 6:52 am

3.4 rating from 49 votes


Comments feed TrackBack URI

Uh? Concatenation? I think everyone else calls it “tiles”.

Old news, Google on “tile+css” and you get about 1 million hits.

Comment by Mark — April 26, 2007

Hmm, been doing this for years.

Comment by mud — April 26, 2007

Well, in the news it’s the other way round: they do not tile it, they took several separate icons which are used together in a toolbar and put in in one image. With CSS backgrounds they are showing only a part of this bar-image, so that it looks like a single icon image.

This could be really a speed boost because connections to the webserver are limited …

Comment by F.o.G. — April 26, 2007

I agree with the others… that’s old.

And hovers using opacity? When is the next article coming telling us the use of font-size: 12pt is somehow new and creative….?

Comment by Nick — April 26, 2007

FoG: The technique you mention is old and exactly what is called “tiling”. See A List Apart for examples…

Comment by Nick — April 26, 2007

I don’t like his XHTML. Why use img when you can just set backgrounds on the (already existing) a tags? Since clicking on the icon should perform an action, using the anchor tag makes a lot of sense semantically, but you also reduce the amount of code you have (including duplication between the img‘s alt attribute and the text of the link), eliminate the need for a spacer image, and get better support for the :hover effect in older browsers…

And yeah, the others are right — this is an old idea.

Comment by Dan — April 26, 2007

I think another name for this is Sprites. In Firefox, go to and scroll through the Media tab in the Page Info dialog to see a few. They’re very shy.

Still, it’s always good to see the a different take on the technique.

Comment by Don — April 26, 2007

I’ve been doing so in a very long time already.

Comment by Andy — April 26, 2007

Good to know it’s called tiling :) I wasn’t aware. I’m sure there are others that don’t know anything about ’tiling’ so no biggie.

Because I’m always up for learning new things, I’m curious how you would set up your handy-dandy XHTML and set a ‘concatenated’ image as the background of an a tag without letting the other icons show through….I suppose you could tile the images vertically, but then you are assuming the user doesn’t increase/decrease their font size on the browser. Is there a method that I’m blissfully ignorant of? I’m also unsure how an image as a background on an a tag is more semantic than an image being on an img tag….

Comment by Matt — April 26, 2007

Perhaps it saves a few bytes here and there, and apparently the connections are the bottlenecks anyway. I think I still prefer a good old <img> tag.

Comment by David Carrington — April 26, 2007

@Rui Lopes
Right…but that is an anchor tag without text….

Comment by Matt — April 26, 2007

This site covers the opacity issue very thoroughly:

Comment by mik — April 26, 2007

Don’t forget to overflow:hidden and set width and height, that way other images on the sprite will not show through. There is/was a bug in Safari Mac, I can’t remember exactly what it was, but I think it ignored the background:no-repeat and so I ended up putting some images at the far right side of the sprite with enough white space further to the right so that you did not see other images from the sprite. This was only needed when I used the image as an icon for a text label (ie. [x] Label)…done by using text-indent in combination with everything above.

Comment by Dan Ruspini — April 26, 2007

At what point, exactly, is this technique worthwhile? The example depicts a lot of work (and many bytes of markup) to shave off five tiny requests. The technique seems sensible in the case of large hovers, since you eliminate the load-delay of a separate hover image, but when would this actually save you bandwidth?

Comment by Eric — April 26, 2007

It doesn’t save much bandwidth. What it saves is round trips to the server.

Comment by Michael Geary — April 26, 2007

The only problem I have with using Opacity for an inactive state is that in Firefox, changing opacity of an element on the page has weird pixelation effects on all othe text on the page.

Comment by Matt King — April 26, 2007

I didn’t know it. so it’s a useful piece, for me!

Comment by terry xu — April 26, 2007

You may want to add the following JavaScript snippet on top of your page to get rid of the IE6 CSS background-image flicker (on hover) bug:

try {

Comment by Dan POPA — April 26, 2007


In very heavily traffic’d websites, that need to perform well (ie. Yahoo, Google, etc…) reducing the number of requests in every possible way becomes very important. This has been documented by various people are certainly practiced within the industry. We’ve seen this topic on Ajaxian and other blogs in the past so it should be something that every website developer is aware of.

Comment by Dan Ruspini — April 26, 2007

“I think another name for this is Sprites.”
True – (and ALA called it that earlier)

“The example depicts a lot of work (and many bytes of markup) to shave off five tiny requests.”
One other reason to use this speed. In the above pattern, there’s the Lemmings example where the developer Tino used sprites to make lemming movement smooth. Otherwise IE6 might have tried to keep reloading images every time they change.

There’s also an opportunity for someone to make a server-side library that uses image-magick to make this process transparent to the web developer.

Comment by Michael Mahemoff — April 26, 2007

> It doesn’t save much bandwidth. What it saves is round trips to the server.

Actually, if you use well-compressed 8-bit PNGs, on batches of pictograms or menu images (quite similar images), you can get a 10-15% reduction in size, on top of the drastic reduction in HTTP hits.

Doesn’t work near as well with GIFs by the way.

Comment by Masklinn — April 27, 2007

Stop jocking and please …. buy a good ajax book .

Comment by EPO — April 27, 2007

Well like a muppet I had been using a javascript for this (blush). So thanks for the pointer (really should have been scoped out by me quite some time ago!).

Comment by fusion — April 28, 2007

Essentially this is what YUI is already doing (on their buttons for instance)

I’d like to take this methodology and apply it to a web-app with lots of icons though (TinyMCE maybe!?!?) – maybe when I’ve got time! ;)

Michael Mahemoff makes an interesting point about a library that could take care of this transparently with a server-side image rendering program. — But the ultimate question… is it worth the effort!?

Comment by VoR — April 28, 2007

umm isn’t this just plain commeon sense. it doesn’t need a name or a buzzword. this guy’s implementation isn’t very semantic, however. The fact that some of these people regard this as ‘new’ and ‘exciting’ makes me ‘chuckle’ ;-)

Comment by Jamie — April 30, 2007

> is it worth the effort!
It usually is, as:

* it drastically reduces the number of HTTP hits on the server (which is never bad if it doesn’t result in any bandwidth hike)
* on palletized images (GIF, PNG) it prevents the duplication of the palette, which results in a somewhat lower final filesize
* on pretty much any image it gives a bigger compression field which usually results in better compression, especially with PNG (GIF is not as good there)

For example I took the 16*16 Qute iconset (, recompressed it with PNGOptimizer, it yield 60 files and 43427 bytes (it’s PNG/32 with transparency).

I then tiled it on a single image (10*6 icons) in photoshop, saved that (as another PNG/32 image, no cheating with PNG/8), and ran that through PNGOptimizer. The result? A single file, 36023 bytes.

Size reduction of a bit over 17% (7404 bytes), which is definitely noticeable.

Of course one can argue that not all of these icons would be used on a single page (very true), but for elements that are always used together (e.g. menu images) you’re looking at that kind of savings (definitely over 10%, with PNG/8 images and graphics that fit the PNG compression algorithms I’ve seen savings in the 25% range) and a heavy slash in the number of HTTP connections to the server. Gain + gain = no reason not to do it is there?

Comment by Masklinn — May 1, 2007

Tiny MCE already uses a sprite technique for the toolbar icons, it’s just not switched on by default.

Comment by Jim Beam — June 10, 2007

Leave a comment

You must be logged in to post a comment.