I have mixed feelings about obfuscation.
Obfuscation serves a purpose (maybe), but it's not compression. Sure,
the first obvious step to obfuscation is to remove comments and
whitespace, and that makes the file smaller, but then it moves on to
more of a "security" role in an attempt to hide your IP. At the end of
the day, the browser needs to understand the JS enough to run it, and
therefore someone can de-obfuscate it if they care to.
On the other hand, I'm sure that on-demand
compression/decompression takes some CPU time.
Yes and no. You can get a lot of compression for a little CPU, it's that
extra 10% that takes 90% of the time. But even if you go for heavy
compression, most web servers will cache the compressed copy of the file
anyway so you only take the hit on the server once, after all, it's the
same file they're compressing over and over, why not cache it.
On the client-side, most browsers have more CPU then they know what to
do with, so decompressing (which is the quicker of the two operations
anyway) is a nit. Actually, you may see a performance _increase_ due to
compression. Remember Stacker from the old PC days. The theory was
simple, sure we take a hit in CPU for the compression/decompression, but
we read less from the disk so things are faster. Well, same argument
holds here, sure you take a hit from the decompress, but you had to
download 7K not 27K, so you more than make up for the decompression
time. Also, modern browsers will cache that decompressed file anyway, so
you're only talking about a one-time decompression hit. When looking at
compression settings on the server make sure you look at the caching
setting too. You can eliminate a _lot_ of requests with client-side
caching, and that's a win-win since you save the bandwidth and they get
the page faster.
-Walden
midrange.com
