Saturday, October 18, 2008

lossy javascript compressor targeting gzip

There is a website that compares various popular JavaScript compression utilities. The goal is to reduce bandwidth. Looking at the results though you see that just turning on gzip compression will give you the biggest win for your effort and reduces the size of the data that is sent to ~40-20% and beyond that the best compressors seem to only half that getting down to ~15-7%. So it should be a given that you will turn on gzip compression on the server. Looking through the compressors that compress variable names you see variable names such as a,b,c,d,e etc. What if you used a, aa, aaa, aaaa, etc? Because the goal is to produce lossy compression why not tune the javascript compressor to not return a file that is small, but to return a file that can be highly compressed by the algorithms used by gzip? Some ideas to re-write the code so the same behavior occurs include:
- Use a, aa, aaa, or maybe thisthis, thisthisthis or limit yourself to the most common letters used f, o, r, e, t, n, etc Need to test out what would work best.
- Always adding an else statement so the pattern }else{ would always appear
- Making sure spacing is consistent (I think most do this already)
- all if statements use {}
- There is always a ; before a } I noticed that some of the compressors removed the ; after a return because you technically don't need it, but that makes two types of } blocks, those with a ; and those without.

Update: ticket filed on the YUI compressor


Mr. B said...

dude, that's actually an excellent idea. Its such a good idea, are you sure someone hasn't already done it?

Benjamin Meyer said...

Looking at the compressors it doesn't look like anyone is doing this.