11 December 06

3 Ways To Shed Your Javascript Pounds

Last week, I talked about Javascript bloat on major sites such as Digg and Slashdot. Now I will show you three different ways to stop the bloat and trim the fat. It’s time to shed those pounds.

Here is a screenshot from Textmate to show you how I usually code.

As you can see, it’s fairly neat, tidy and logical. If your code isn’t any of them, then it’s a good start to clean it up. It will help in the long run, especially when you come back to it in the future.

The script I will be using is a fairly average sized script. It’s 150 lines long and 4,118 bytes. It’s also using the Prototype Javascript library, which means that this script in particular would be slightly smaller anyway (but remember, the script and Prototype together would be much larger the same script written in normal Javascript). And remember, it’s always a good idea to work with uncompressed scripts first and always back them up.

#1: Xtreeme Javascript Optimizer

This is the most simplistic compressor out of the three. This tool will strip out tabs and empty lines, and also any unnecessary semi-commas. This still means the Javascript is still makes logical sense and is quite readable, albeit not spaced very well. The new compressed file is now 137 lines of code and 3,416 bytes. That is 82.9% of the original size, so a reduction of nearly 17% just by taking a few unnecessary things out.

#2: ShrinkSafe

ShrinkSafe, part of the Dojo project, works in a similar way to Xtreeme, but goes one step beyond. It replaces variables within functions with shorter names (e.g. var someVariableName would become var _s). This variable changing will still make your code function as normal, but it will be less intuitive when reading. With ShrinkSafe, the script is now 114 lines of code and 3,298 bytes, which is 80.1% of the original size or close to 20% off.

#3: Packer

Dean Edward’s Packer, used to squash jQuery from 50k to 19k, is a compressor and obfuscator, meaning that not only does the file size reduce but readability decreases, which is good if you’re the secretive type. Once you’ve compressed a script, it’s almost impossible to convert it without the decoder (also on the Packer site) so it’s definitely a good idea to work with an uncompressed script.

Packer is also very strict. It took me about 20 minutes to figure out why my script wasn’t compressing correctly. Anywhere you’re supposed to put a semi-colon in Javascript – end of functions, etc – you will need to have one for the packer to work. My script is now just one long line of code, and has been compressed down to 2,733 bytes. That’s now 66.4% of the original size, a massive 33% reduction in size.

There are obviously advantages to each method; Xtreeme being easy to work with after compression, ShrinkSafe is compressed further whilst still being readable, Packer is highly compressed. But the advantages of one method are exactly what other methods lack.

There are other methods to stop the bloat of server requests, in particular Apache’s mod_gzip module which compresses HTTP requests on the fly, so that all your HTML, CSS, images and more is compressed, which can save up to 50% of your bandwidth.

You wouldn’t export your web images as 100% quality JPEGs and you wouldn’t leave in large commented sections in your HTML. Why should Javascript be any different?

Enjoy this? Subscribe to the feed for the very latest updates.