Simon Kenyon Shepard :: justLikeThat.

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!).

I stole this image

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.

I’ve recently been converted to the practice of using jQuery custom events. At first I didn’t really see the point but then as time wore on it started to dawn on me how much more extensible it made the jQuery plug-in architecture and allowed a level of pseudo MVC, where the DOM translates literally into your view.

The example I’m going to illustrate it’s usefulness is a simple drag and drop, I recently found myself having to re-implement a drag and drop plug-in in jQuery as the standard UI plug-in although quick to implement was simply not very performant due to the incredible amount of configurability it has.

At first taking from the jQuery UI drag and drop template I started off with an implementation that was invoked by calling the following:

$("foo").dragLite({

containment : "parent",

axis : "xy",

startDrag: function() {foo.bar},

stopDrag: function() {foo.bar}

});

Pretty familiar stuff, like what you’d see on 99% of plug-ins.  So as the age old adage goes “If it ain’t broke…” until another developer came along a few months later and said “I want to hook into your stopDrag event”.

UH OH.

Well, you could do, but the only way to do that is to edit my original initialisation call and add in a call to your function in my anonymous function, which you could do, but is pretty messy, creates two fairly deep dependencies and could mean that if either of our code breaks, the functionality will not fail in a graceful way…

Clink. The penny drops. For the last few months, some people at work, some people on the web (dean edwards for one wrote an interesting post), and random tramps I met on the street, had been banging on and on about the custom event functionality in jQuery and this was why.

In my first example, I had had to pass my anon function into the last function through the initialise code, so my plug-in code looked something like this:

var dragStopped = function(event) {

//some stop drag code here

if(event.data.stopDrag) {

//execute the call back

event.data.stopDrag();

}

}

which as mentioned before means if anyone wants to add in an additional call back they have to do this:

$("foo").dragLite({

containment : "parent",

axis : "xy",

startDrag: function() {foo.bar();},

stopDrag: function() {foo.bar(); someOtherClass.someOtherCallBack();}

});

However, what if we abandon callbacks for custom events instead, so the plug-in code becomes:

var dragStopped = function(event) {

//some stop drag code here

//trigger custom event bindings

$(this).trigger("dragLite.stopDrag");

}

which won’t fail if we have no functions bound and our initialisation call becomes this

$("foo").dragLite({

containment : "parent",

axis : "xy"

}).bind("dragLite.stopDrag",foo.bar) ;

then all my other developer has to do in his code is

$("foo").bind("dragLite.stopDrag", someOtherClass.someOtherCallBack) ;

which he can do anywhere in the code, independent of whether the drag functionality has been implemented yet.

Pretty Neat, and most definitely worth doing for increased stability, better code flow and less work for you!