a little madness

A man needs a little madness, or else he never dares cut the rope and be free -Nikos Kazantzakis


JavaScript Compressor Comparison

So following on from last weeks post I have taken a closer look at the common tools used to compress JavaScript. Below is a graph of the compression ratios that these tools achieved when applied to ext-all-debug.js, the uncompressed JavaScript from the popular ExtJS framework :

Some points to note are:

  • GZip is rather different from the other forms of compression in that it a compression of the content rather than the JavaScript, and therefore can be applied to compressed JavaScript. I have included it in the graph to provide an indication of the level of compression it can provide.
  • The simple compilation option was used with Google Closure as this is typically the one that will be used. For a discussion on why, check out the excellent post on A Log of Javascript.
  • Packer is similar to GZip in that it is more a compression of the content rather than JavaScript itself. Unlike GZip however, it has a runtime cost associated with the unpacking of the JavaScript on each page load.

Below is a graph of the processing time required for the above compressions:

Aside from Packer, there is not a lot of difference, and since all of the processing is done before deployment the compression cost does not impact the performance of the JavaScript.

The final graph below shows the compression ratios where each of the compressed JavaScript files are then GZipped, as is more typical of production environments.

In the final analysis it is clear that you should GZip your JavaScript, although be aware that not all browsers correctly handle GZipped content. As to which of the other compression tools you use, it comes down to your JavaScript. My experience showed Packer to produce the best results for ext-all-debug.js whereas Julien found that the YUI Compressor is a better choice for jQuery. CompressorRater can help with this task although it does not yet include Google Closure.

Liked this post? Share it!

8 Responses to “JavaScript Compressor Comparison”

  1. June 3rd, 2010 at 11:06 pm

    MLeoDaalder says:

    What about the performance of evaluating the script in the browser?
    Does packing/compressing it influence that?

  2. June 4th, 2010 at 2:21 am

    lounsey says:

    I imagine there is a cost to unpack/evaluate the compressed code, and that it differs by both the compression tool and the browser.

  3. June 4th, 2010 at 7:40 am

    Jeremy Bowers says:

    If you haven’t tried this yet, try adding in effect of gzip’ing the stuff coming out of the other processors. In my experience together they do even better.

  4. June 4th, 2010 at 7:54 am

    Greg says:

    For most of those utilities, the compressed code is not really “compressed” per se, it is just “minified.” That is, shorter variable names, removal of white space, comments, etc. So there is no extra cost to “unpack” or “decompress” the code, as it is still just plain text JavaScript that can be read and used by the browser.

    In fact, the browser should (in theory) be able to parse and utilize the code a bit faster, as it does not have to remove comments, or deal with look-ups to long identifiers.

    The only exception to that would be when serving GZipped code. The code is actually compressed (the traditional use of the term) by the web server, and then decompressed by the client browser. There is a small overhead in this, but is still much faster than downloading the larger, uncompressed file.

  5. June 4th, 2010 at 10:11 am

    Witek says:

    Simple web server and proxy server should maintain in-memory cache of gziped scripts and other small items (gzip -9 for best) , and reuse them. It gives best speedup. Some packing like removing unneeded spaces, semicolons, comments can provide some additional saving, but after that further packing isn’t very good idea. Ok, changing identifiers of varaiable and function, removing dead code, inlineing CAN make JS smaller, but it with high probability brake this JS code.

  6. June 4th, 2010 at 10:41 am

    Daniel says:

    As Greg mentions, most of these utilities shrink the JavaScript via minification. The exception to this is Packer, which generates a self extracting package. Where minified JavaScript can be cached, the Packer compressed script has runtime overheads as it must first unpack itself each time it is used.

    @Witek whilst there is certainly a possibility of corruption of minified code, a newer implementations are backed by JavaScript parsers ensuring that the end result is indeed valid and safe to use.

  7. February 22nd, 2011 at 1:16 am

    ekoder says:
  8. October 4th, 2011 at 2:09 am

    Clair Hoberg says:


Leave a Reply