Compressing Web content delivery

Back in March of last year, I wrote about Port80 Software's w3compiler product (see editorial links below), which allows you to compress the size of some or all of your Web content. This in turn reduces your bandwidth demand and provides HTTP 1.1 compatible clients with a faster page download.

The downside of w3compiler is that you have to pre-optimize content before it is accessed which can be a big management overhead for a large and frequently changing Web site.

For IIS-based servers, Port80 offers solutions to dynamically compress Web content: httpZip for IIS 4.0, which offers no built-in compression and IIS 5.0 in which the built-in compression is broken.

For Windows 2003 and IIS 6.0, Port80's ZipEnable 2.0 fixes several serious problems with the built-in compression. As shipped, IIS 6.0 offers no browser compatibility checking which means you could wind up sending compressed content to a browser that cannot decompress it. There's also no graphical interface to most controls such as site level compression and compression schemes. Worse still, all advanced settings are only accessible via an API.

Interestingly there are situations where Port80 suggests that httpZip is a better choice than ZipEnable and IIS 6.0's integrated compression. These are when reporting of compression and bandwidth performance is required, where caching of dynamically compressed content occurs (the server will keep recompressing this content under IIS 6.0), where you want to control compressions depending on the MIME type, or where you need to control when IIS 6.0's built-in compression occurs in the request/response cycle.

For a single server httpZip is priced at $300, and ZipEnable costs $80.