Using efficient markup will help keep bandwidth usage down, and make pages load faster. If that isn’t enough, and you need to reduce document size even further, server side compression is worth taking a look at.

As the visitor count here has increased, my monthly bandwidth usage has gone up a lot. It’s not yet at the point where my host will start complaining, but to delay reaching the bandwidth limit I started looking at ways to enable on-the-fly compression of all documents except images.

Doing so turned out to be pretty easy, since this site is hosted on a server running Apache 2.0, which includes the mod_deflate module. To enable the DEFLATE output filter provided by mod_deflate I just used the following example from the Apache website (after kindly asking my host to recompile Apache with mod_deflate enabled):

  1. # Insert filter
  2. SetOutputFilter DEFLATE
  3. # Netscape 4.x has some problems...
  4. BrowserMatch ^Mozilla/4 gzip-only-text/html
  5. # Netscape 4.06-4.08 have some more problems
  6. BrowserMatch ^Mozilla/4\.0[678] no-gzip
  7. # MSIE masquerades as Netscape, but it is fine
  8. BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  9. # Don't compress images
  10. SetEnvIfNoCase Request_URI \
  11. \.(?:gif|jpe?g|png)$ no-gzip dont-vary
  12. # Make sure proxies don't deliver the wrong content
  13. Header append Vary User-Agent env=!dont-vary

If I make other file types that won’t benefit from compression available, like other images, movies, and compressed archives, I’ll just add those to the list of excluded file types.

Since I enabled the DEFLATE filter, overall bandwidth usage has gone down quite a bit. I’ll have to wait a while to see the exact numbers, but it looks like most documents are now 40-50% of their uncompressed size.

I’m not sure how much CPU deflate uses, but I haven’t noticed any performance problems yet, and my host hasn’t notified me of any problems either, so it seems to be pretty efficient at the current (default) setting. The compression level can be increased by using the DeflateCompressionLevel directive, but that will use more CPU time, so I’ll leave it like it is for now.

Posted on August 10, 2004 in Web General


  1. I’ve been using a free compression module for ASP.NET for quite some time now. I never noticed a performance hit. If it’s a concern, try adjusting the compression level back and forth.

    HTML is very repetitive by nature and therefore compresses really well. On average, a 70K page on my site compresses to 6K and it happens incredibly fast.

  2. August 10, 2004 by Roger (Author comment)

    Interesting. I’ll take a look at that if I encounter the need for compression in a .NET based project.

  3. Don’t worry about a performance hit - it’s barely measurable and the bandwidth savings far exceed the cost of a few milliseconds of CPU time.

    I’ve been using mod_gzip for a couple of years now. Since the beginning of this year, I have achieved an average data compression ratio of 59.20% (and have thus served almost 12GB of data LESS than I would have done without content compression. Page service times for the same period have averaged 0.97 seconds - so, the CPU impact has been minimal.

  4. Interesting. Does anybody know of a server-side compression technique for ASP Classic pages?

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.