You are just rediscovering what we’ve all been advocating for quite a long time now: “stay away from “advanced” JavaScript compression schemes that look attractive on paper, but end up degrading the performance of your site”. Instead, use a good (i.e. safe) minifier and Gzip compression. Case closed.

I used this packer http://dean.edwards.name/packer/ with shink variables but no base62 encoding and then level 1 gzip (fewest cpu cycles for both encode and decode) and it far outperforms any javascript compressor. jQuery becomes only half a K larger than it’s compressed counterpart and it caches better and is ready to execute faster.

Really, all these compressors are just javascript coders showing off how cleverly they can code but they are wasting their time that could be used on other efforts. Gzip is proven, works faster and is available on all modern browsers. Problem solved. (I just hope they aren’t trying to do the compression so they can bloat the libraries to over 100k and still boast how small the distribution size is, which is meaningless)

Sorry. Ignore previous comment. Noticed you were talking about base62 and stuff like that. From what I know, it is only about 200ms overhead at most.

You’re completely missing something. Pack your script using any of the packers mentioned and upload it to your server. Do NOT do it on the fly. Do it once and upload it. Then turn on gzip compression on your server. Your server will gzip a file once it is requested and CACHE it. It will only gzip it once and then serve the cached version. There is NO performance hit. There is only performance improvement.

You are absolutely right. However, only Packer (as far as I know) with the base62 encoding option enabled, will output code that requires some extra CPU cycles on the client. JSMIN, the Dojo Compressor and the YUI Compressor only remove white-space characters and comments, and the last two do a light obfuscation as well. If you read this article, you’ll see that jQuery, for example, would be better off distributing their library using a different compressor, and advocating the use of HTTP compression.

Regards

Why not just “pack” the code instead by removing whitespace and renaming variables to shorter size and then just use gzip web compression (aka http compression). Then when the code is cached in the visitor’s browser, it’s ready to execute on every load.

I did some rough tests and I was able make a “packed” gzip version of jquery within 1k or less of the size of the currently distributed “compressed” version – and the packed version loads quicker!

Most web designers go to great lengths to get even 100ms off a page load, why add 100ms to the client side just so a library developer can boast that they are 1k smaller than another – it’s meaningless!

http://www.julienlecomte.net/blog/2007/08/21/gzip-your-minified-javascript-files/