Dean Edwards /packer/ compression tool
We’ve been working pretty hard on CNET’s new javascript global framework. It’s based on Mootools with a bunch of other things mixed in. Last week I took on the task of documenting the entire Mootools library, now online. I struck up a conversation with the author of that library, Valerio Proietti from mad4milk.net and have since been granted access to contribute to the source of that library (thanks Valerio!). Mostly my contributions have been focused on the docs, but I’ve also helped out with a few bugs and the like.
Anyway, one of the things that Mootools turned me on to was Dean Edward’s /packer/, which is an awesome javascript compression tool. This thing compresses our libraries dramatically, sometimes as much as halving their file size. We’ve actually put our new global libraries into production on news.com and I just got around to actually testing the efficiency of the compression algorythm.
Our global framework file, which when packed clocks in at 30K (it contains about 60% of the full Mootools library, the rest is legacy support for old Prototype.lite scripts - more on this later - and then classes and functions we’re using throughout the network), if you use the /packer/ only to remove comments, line breaks, and spaces, it clocks in at 42K.
I used the firebug console.time() function to compare how fast the browser parses each of these files and the results have me wondering which is better.
It takes about 150ms to parse out the fully compressed file, while only 10ms to parse the one without the spaces and line breaks. Is that 25% file size break worth it? Think about this when we compress all the javascript on our network this way (we’re working on a big refactor of all our crufty legacy stuff). If the page is getting delivered 100K of javascript, that could mean half a second to decompress the fully packed version, or an extra 25K download time.
On the first pageload of such a document the trade off might be worth serving the fully packed version, but every single page after that, when your browser has the document cached, its still got to decompress it. Is it worth it?
I’m starting to think not.
Thoughts?
October 26th, 2006 at 11:47 am
First off, nice freaking work on the mootools docs! I came across them earlier today, and was impressed. Congrats.
But onto the topic at hand. I too fear the eval that is at the start of all ‘packed’ code. It makes things small, but there’s a lot for it to eval. Personally I’m a fan of the whitespace stripper, it’s less for their browsers to load, but it’s not executed every time they load the page. And page responsivenness, especially with dom stuff, is not a minor issue.
November 24th, 2006 at 11:37 am
It is not the eval that is slow. There is only one eval and it is equivalent to document.write in terms of speed. The overhead is cause by string replacement. There is only one of these but it executes over (in this case) a 30K string.
You have to do the math yourself. If you are getting a lot of one-off hits then packing is the way to go. If you are confident that you will get a lot of return visitors then just whitespace and comment removal may be sufficient. Like a lot of things this is a judgement call.
The next version of packer will provide variable/argument substitution for a higher compression rate and proper obfuscation. This also makes the minified (whitepaces stripped) version much smaller too.