Thursday, April 26th, 2007
Faster Page Loads With Image Concatenation
<p>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):
-
-
#sidebar img.icon{
-
filter:alpha(opacity=50);
-
-moz-opacity: 0.5;
-
opacity: 0.5;
-
}
-
-
#sidebar img.icon:hover{
-
filter:alpha(opacity=100);
-
-moz-opacity:1.0;
-
opacity:1.0;
-
}
-








Uh? Concatenation? I think everyone else calls it “tiles”.
Old news, Google on “tile+css” and you get about 1 million hits.
Hmm, been doing this for years.
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 …
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….?
FoG: The technique you mention is old and exactly what is called “tiling”. See A List Apart for examples…
I don’t like his XHTML. Why use
imgwhen you can just set backgrounds on the (already existing)atags? 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 theimg‘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.
I think another name for this is Sprites. In Firefox, go to yahoo.com 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.
I’ve been doing so in a very long time already.
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.
@Dan
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….
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.
@Rui Lopes
Right…but that is an anchor tag without text….
This site covers the opacity issue very thoroughly:
http://www.mandarindesign.com/opacity.html
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.
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?
It doesn’t save much bandwidth. What it saves is round trips to the server.
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.
I didn’t know it. so it’s a useful piece, for me!
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 {
document.execCommand(‘BackgroundImageCache’,false,true);
}catch(ignoreme){}
@Eric
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.
“I think another name for this is Sprites.”
True – http://ajaxpatterns.org/Sprite (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.
> 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.
Stop jocking and please …. buy a good ajax book .
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!).
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!?
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’ ;-)
> 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 (http://www.quadrone.org/graphics/), 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?
@VoR
Tiny MCE already uses a sprite technique for the toolbar icons, it’s just not switched on by default.