To make a rich web UI, you’re going to need a sweet Javascript library to handle your outrageous animations and the like (along with the actual Ajax, DOM manipulation, and event handling, which are of secondary importance…)

But have you seen these things? They’re massive. Prototype (the default Javascript framework of Ruby on Rails) alone is a 50K file, growing with each release, and that doesn’t include animations. Throw in a rich text editor, and you’re at 300K worth of Javascript. To be fair, you get a lot with these libraries, but wow! That’s a high price to pay for a flashy UI.

Turns out if you’re serving a lot of textual content on your page (that means YOU, Joe Blogger!) then you can have your server start doing some work to reduce the bandwidth needed to view your site. Just zip the textual stuff on its way out, and modern browsers know how to unzip it on the client machine.

You can save significant bandwidth (this is just for my blog’s plain HTML):

A lot of people already know that this is possible, but not how to set it up or ensure it’s working. I thought my sites were using compression for the past few weeks, but being mildly naive and equally retarded, I trusted the online Apache docs without even testing to ensure compression worked. So here’s how to do it and test it.

How to get it going in Apache

In Apache 2, it’s pretty simple. First, enable mod_deflate.

On Ubuntu, that’s as easy as
# a2enmod deflate

For other distros, I expect that there’s a little more trickery involved, but not much.

Now, all you need to do is tell Apache what to compress. The Apache docs seem to think you can it going with this simple shortcut line, added to the top of your site’s config file (/etc/apache2/sites-enabled/000-default on Ubuntu), which will apply to all virtual hosts.


AddOutputFilterByType DEFLATE text/html text/plain text/xml


However, this did not work for me. I assumed it did. A few weeks later, I discovered some tools to verify that compression was enabled on my servers, and lo and behold it was not. Thankfully, they also list an alternate configuration, which works just fine on my servers:

# Insert filter
SetOutputFilter DEFLATE

# Make sure proxies don't deliver the wrong content
# Header append Vary User-Agent env=!dont-vary


Restart your web server to enact the changes:
#/etc/init.d/apache2 force-reload

Test it

Here are some really useful online tools-

• whatsmyip.org has a gzip test — it’s a fast tool that shows you whether you have compression enabled, and nothing else. I like it.
• Port80software, in addition to telling you about the state of your server’s compression, can also look at the cache headers being sent. This is great if you’re testing some caching code.
• The classic Web Page Analyzer shows you the bandwidth used for all of your resources (html, images, javascript) in a useful way. It also tells you, hidden away in a paragraph somewhere, if server-side compression is enabled.

Further reading: Yahoo UI uses a modular Javascript approach (so does Dojo). See YUI’s impressive bandwidth numbers, including comparisons with gzip enabled.