Comments on: JavaScript Compressor Comparison

By: Clair Hoberg

Clair Hoberg — Mon, 03 Oct 2011 15:09:40 +0000

ÿþ|

By: ekoder

ekoder — Mon, 21 Feb 2011 14:16:43 +0000

There is one more tool for js compression http://www.webrankstats.com/tools/javascript-compressor/
and for css compression http://www.webrankstats.com/tools/css-compressor/

By: Daniel

Daniel — Thu, 03 Jun 2010 23:41:58 +0000

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.

By: Witek

Witek — Thu, 03 Jun 2010 23:11:37 +0000

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.

By: Greg

Greg — Thu, 03 Jun 2010 20:54:24 +0000

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.

By: Jeremy Bowers

Jeremy Bowers — Thu, 03 Jun 2010 20:40:54 +0000

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.

By: lounsey

lounsey — Thu, 03 Jun 2010 15:21:34 +0000

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

By: MLeoDaalder

MLeoDaalder — Thu, 03 Jun 2010 12:06:31 +0000

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