Comments on: Compression of JavaScript programs

By: Alex Scott

Alex Scott — Sun, 19 Feb 2012 19:23:11 +0000

Will you continue to develop on CrunchMe?

By: m

Mon, 09 May 2011 13:17:59 +0000

Again, this is not about lowering network bandwidth nor faster page loads. It’s about smaller JavaScript files, even if they are loaded locally (not from a server).

By: witek

witek — Sun, 08 May 2011 19:57:26 +0000

Precompress using gzip -9, put as static file, and configure apache properly. Instant win and big compatibility. (removing comments and redudant whitespaces, semicolons will also help). As of using clousre compiler and other “pseudo-compression” methods I will be very cearfull (base64 and other can really mess output). But automatic renaming of variable, arguments and function names, as well inlineing functions used once should be safe (if you are not writing library, is shiping and not debuging code, and there are no “eval”).

PNG trick is not a trick. It is ugly hack.

By: ElegantCoder

ElegantCoder — Sun, 08 May 2011 14:49:11 +0000

Thank you for the great posting!
I translated this post into Korean. The translation is posted on my blog.
You may see it here:
http://elegantcoder.com/binary-compress-js

By: m

Mon, 02 May 2011 20:22:17 +0000

Please keep in mind that it may not always be true that compression saves power or even “transfer” time, though, since executing the unpacker takes both time and battery power (regardless if it’s a JS unpacker or a “native” gzip unpacker).

By: Dennis

Dennis — Sun, 01 May 2011 13:40:28 +0000

Is there any reason that the mobile device keep cache in raw format? Even the cheapest compression saves IO time and power.

By: Iouri Montreal

Iouri Montreal — Sat, 30 Apr 2011 05:49:56 +0000

It would be cool if somebody added a service like that to google apps. I use google’s optimizer that is hosted there. Pretty convenient.

By: m

Fri, 29 Apr 2011 19:56:31 +0000

Good comment. Actually, the decompression is quite fast in modern browsers, so for most applications it should not be noticeable, but you are right that if you (re)load pages alot it could give you a performance hit. For comparison, you can try another demo of the LZG decompression here (I usually get over 10 MB/s in that test).

By: Jared Jacobs

Jared Jacobs — Fri, 29 Apr 2011 16:46:36 +0000

Great post, clever tricks. One thing I looked for in this post and comments, but didn’t find, was a comparison of the running times of these different methods. I’d imagine these methods are not recommended for any real website unless most of its visitors had fast computers and slow connections (AT&T mobile customers, perhaps?). A significant disadvantage of these methods is that the browser has to do several layers of unpacking/decoding of JS code on every page navigation, even when the script is just coming from the browser cache.

By: m

Thu, 28 Apr 2011 21:00:43 +0000

Oh, I see now. Maybe I wasn’t clear in the post, but one of the constraints of this whole exercise is to keep both the unpacker and the packed data within the same file. If you are allowed to split the two, an even better approach is to load the packed JS from a separate PNG image (and never bother with UTF-16 encoding).