if(JTeam && Toolman) {blog.read();}

I love the JavaScript libraries that give us the ability to manipulate DOM nodes with ease; adding any kind of dynamic content, and allowing subtle but slick effects to add polish to your websites.  Unfortunately, the weight of all these tools add up.

I think that it is common courtesy (as well as good business) to avoid sloppy usage of those kilobytes that we expect our users to pay for to access our content. I think its akin to having oversize images and having the browser scale them down - wasteful. How long would it take to switch the original source JavaScript for a compressed version? Probably less then 10 minutes. If you write a lot of code inhouse, you could even automate the compression for production via your Maven builds.

The only reasons to not have compressed code is if you are debugging in a browser and stepping into the library, or learning the API via the code. In either case you are not looking at production code!

My personal favorite libraries (JQuery and Scriptaculous+Prototype) are available from the authors ready compressed in 2 styles. JSMin , where the code is directly executable, and Dean Edwards’ Packer which generates a packed codeblock, that unpacks in memory. The latter takes some CPU time to unpack and so is not immediately available. The unpack is tolerable if you are trying to squeeze that last extra kilobyte, as it can provide greater reduction in download size then the JSMin equivalent.

Which to choose? I found a great writeup on the whole subject of minimisation. Its section dealing with these 2 really helped me decide which way to go in a project. Let me quote a piece from an article I recommend any serious web developer should read:

http://www.seifi.org/css/how_to_boost_your_javascript_and_css_performance.html

JavaScript Shrinking

1. JSMin removes extra white-space and comments. It also reduces the line count by increasing the maximum line width. The result a bit uglier and harder to read and debug but also a bit smaller. Unlike ShrinkSafe, though JSMin does not edit your function arguments. …{trimmed for brevity}
2. ShrinkSafe removes extra white-space and comments, but keeps one statement per line which is easy on the eye if you decide to edit your shrunk file. It also shrinks function arguments by replacing them with consecutive _## values which tends to reduce the files size some more. …{trimmed for brevity}
3. Packer has a few options you can choose to minify your scripts. The normal option removes extra white-space and puts the entire file in one super long line. You can also choose to shrink function as well as encode your script using a base62 algorithm. You can try it online. Although your file size is considerably smaller, depending on the complexity and cleanliness of your code (see JSLint above) using the two options in Packer might introduce errors with your code. In my case I had no problems with them.
4. MemTronic - Hardcore shrinkers out there can try this online tool which produces the smallest file size in my tests. Be warned that this is only for the braveheart coders, has some known issues and may have some side effects.

In the authors test, the Prototype library is compressed from 71,260kb down to 54,035kb with JSMin, a saving of 24% - not bad. The packer file, however, managed to get down to 27,634kb, a saving of 61% from the original! I should stress that this was with all the dials turned up to 11 with the compression levels. Aggressive packing is very sensititive to poor coding, so consider the quality of the source code when choosing your own settings!

What are you trying to maximise: bandwidth or performance? Do your customers require absolute minimal file size, or is a slight startup responsiveness advantage and smaller memory footprint more important in your application? I don’t have an answer for your situation - they are your customers!

Thanks to the author of the above quote, very useful article.

This entry was posted on Thursday, April 24th, 2008 at 9:29 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.