I enjoyed this very interesting post on ydn. The post is about the benefit of reducing the number of packets, not just the total file size. More interesting to me was this small note:
If your app sends largish amounts of data upstream (excluding images, which are already compressed), consider implementing client-side compression. It’s possible to get 1.5:1 compression with a simple LZW+Base64 function; if you’re willing to monkey with ActionScript you could probably do real gzip compression.
So to try this out I implemented LZW compression in javascript, except instead of using Base64, which adds more complexity to encoding and inflates the file size quite a bit, I used a trick I’ve seen elsewhere: use the unicode character equivalent to the decimal code output by the LZW algorithm. For the example I used the first 256 first characters in the unicode set as the allowed characters. This breaks any non-latin script for this example, but this proves the concept. I was able to get decent compression. Using the 800 byte example string I got the output down to 705 bytes. In firefox encoding took around 2.38ms, and decoding took a little less. In safari encoding only took .83 milliseconds.
Not sure if this is really worth it or not, but its a cool thing to try out. I think in general just reducing the size of upstream data when possible is probably worth it, but like everything only testing will really say for sure.
Checkout my example here. And get the code here.