I spotted this on Ajaxian today:
Vlad Vuki?evi?, a leader in the Mozilla community (and brought us cool stuff like Canvas 3D!) has spoken up on the internals of the browser, which shows you the trade-offs for the spriting approach:
The biggest problem with CSS sprites is memory usage. Unless the sprite image is carefully constructed, you end up with incredible amounts of wasted space. My favourite example is from WHIT TV’s web site, where this image is used as a sprite. Note that this is a 1299×15,000 PNG. It compresses quite well — the actual download size is around 26K — but browsers don’t render compressed image data. When this image is downloaded and decompressed, it will use almost 75MB in memory (1299 * 15000 * 4). If the image didn’t have any alpha transparency, this could be maybe optimized to 1299 * 15000 * 3, though often at the expense of rendering speed. Even then, we’d be talking about 55MB. The vast majority of this image is blank; there is nothing there, no useful content whatsoever. Just loading the main WHIT page will cause your browser’s memory usage to go up by at least 75+MB, just due to that one image.
That’s not the right tradeoff to make for a website.
I know it’s fairly obvious but I never realised that the browser put all that uncompressed image data into memory before, but it explains A LOT.
For the last few years it seems we’ve focused on how to compress and compress the data we sent over the wire so our load times would be faster, but with this luxury of smaller file sizes we’ve fallen into a trap where we forgot how the browser would cope with all this extra data.
It’s a bit like when you order a 10 foot flat pack wardrobe from Ikea. The 100 mile delivery of the item from Ikea central to your house is easy. We have built a sophisticated road network and big articulated lorries and also you pay someone else to do all that bit for you.
The problem arises when it’s deposited on your doorstep, you wield the gigantic pieces of glass and chipboard through your house into your bedroom, unpack it, get out your drill, screw it all together.
Then you stop for a few hours wondering how the fuck you get this monstrously heavy behemoth off it’s back and against the correct wall of your room. This is the part we did not think about when we ordered it (hint: it usually involves several convoluted contortions, but don’t put pressure on the joints!).
When we made the initial decision, the only problem we could see was the large one immediately in front of us of how to get it to our house, we didn’t stop to think about the problems that might occur after that. This is what we have done with images and browsers.
If it’s true it means a paradigm shift in everyday rounded corner box background images as well as an overall awareness for the weight of images in your site vs. client performance.
One of my favourite apps of this year is spotify, the reason is that as opposed to itunes’ avoirdupois nature spotify has a 16 meg ram footprint. This makes it much faster and responsive than 100meg+ depending on your library size (why itunes should be anywhere near this much and dependant on your library size is beyond me - it’s just one screen of pixels guys!). This matters to me and I suspect on a subconscious levels matters to most of spotify’s fans. So the difference between my website devouring 150meg of your ram (if using firefox x5) vs 15meg DOES ACTUALLY MATTER.
It matters to you, your users and your clients as at the end of the day, your slowness is their bottom line.
Going back to the round corner box CSS case, it means in order to produce performant apps, we should NOT do this:
<div class="wrapper"> <div class="inner"> </div> </div>
Where we stick long background image on two wrapper divs and then use the bottom one as the footer (example), but we actually HAVE to do this:
<div> <span class="header"></span> <div class="content"></div> <span class="footer"></span> </div>
Where as opposed to the first example we have a repeating background on the content div which could potentially result in a 70meg ram saving for your app! This also aligns a lot better with OOCCS and I think is actually more readable on the flip side it is semantically worse as it has two extra empty divs, but lets face it two wrapping divs is hardly perfect and results in a massive image and slow site! An example is here.