The space savings are marginal if you consider the fact the files are likely automatically Gzipped between client and browser http://damieng.com/blog/2007/11/27/shrinking-js-or-css-is-premature-optimization

[)amien

I disagree that it a little compression is not worthwhile. I wrote this blog entry a while back on the topic.

http://brennan.offwhite.net/blog/2007/02/25/how-big-is-your-javascript-library/

I like using JSMin even though it is not the best JavaScript compressor because it simply strips my verbose comments and the excess whitespace. Every little bit helps, especially when you can go from 70KB to 30KB. That is not insignificant for some users. These utilities were a bit a hassle to me though, so I wrapped JSMin and Packer into a MSBuild Task and simplified command-line. You can get Packer for .NET here...

http://brennan.offwhite.net/blog/2007/08/26/packer-for-net-302-released/
http://svn.offwhite.net/trac/SmallSharpTools.Packer/

You can make this a regular part of the build for your website to compress your JavaScript on request. And in your code-behind you can switch between the compressed and raw files using the debug attribute in the compilation section of the configuration to automatically switch when you publish the website while being able to use a tool like FireBug to debug the JavaScript during development.

The point is that you are not saving 40KB because modern browsers and servers compress the file anyway - the actual savings will be a fraction of that size and more like 3-4K.

Yes, you can make this part of your build process but then you have to accept the fact your release build now contains effectively untested code.

In the case of this particular tool it would appear to completely mangle non-ASCII sequences such as currency symbols and accented characters leaving your released version to suddenly have problems displaying, parsing or validating financial values that worked perfectly during all the debug builds.

Sorry, but that risk really should only be taken when you know you have specific bandwidth problems and you can measure how your optimization is helping.

[)amien

So what you are saying is to never compress your JavaScript unless it is helpful and you can minimize the risk. That is always my assumption and I only consider compression when the script is over 20KB. Recently I put together a sample website to use Tidy and I used TinyMCE as an example editor which is an editor run completely with JavaScript. The main script is 208 KB but when passed through Packer it is 87 KB. I can verify that the application works after the compression and if I do have a problem with Packer, which is usually due to not using the semicolons that are optional, I just use JSMin which has a much better chance of working. Note that Prototype does not compress well with Packer because the developers on that project like to leave off the semicolons. The following link explains that in detail.

http://www.andrewdupont.net/2007/02/26/packing-prototype/

Having an easy way to compress my sources I can edit my customizations, like the custom theme that I created for TinyMCE, and compress it during the build. The MSBuild script is here...

http://svn.offwhite.net/svn/SmallSharpTools.Tidy/trunk/build.proj

My custom theme is here...

http://svn.offwhite.net/svn/SmallSharpTools.Tidy/trunk/Website/tiny_mce/themes/custom/

The raw versus compressed is 56KB to 27KB.

Keep in mind that a 56k modem will take 1 second to load a 2KB document and 10 seconds to load a 34KB document. (Many people still use modems or share broadband with many users which effectively acts like a 56k connection) By doing the compression for TinyMCE on these two scripts I save roughly 100KB which will have an impact on users with slow connections as well as the used bandwidth for a high traffic website. And if you are concerned with risk of modifying your source in this way, you should have a test suite. There is a great test suite for jQuery that you can find at the bottom of the following page. You can launch it in multiple browsers yourself to see how well it works and to discover cross-browser problems.

http://docs.jquery.com/Browser_Compatibility

And by pre-compressing and carefully testing your scripts you can then leverage HTTP-Gzip support for additional bandwidth savings. Every little bit helps.

What I try to do is write as little JavaScript as possible by leveraging a library like jQuery which is compressed and tested for me. My LinkMindr website uses a single script for custom behavior and comes in at 0.5KB.

http://www.linkmindr.com/LinkMindr.js

> The raw versus compressed is 56KB to 27KB.

This is exactly my point, you think you are saving 19KB but the reality is that after GZip compression those files are 13K and 11.5K respectively so you are actually saving only 1.5KB for all your efforts (and again, this is only for the initial hit of non-returning visitors).

Given such limited rewards and the risk that the compressed code could behave subtlety different the time would be better much spent optimizing those areas that measurement have shown to be problematic.

[)amien