I knew of HTTP Compression and for some reason never checked to make sure that my webserver had it turned on. The thought was prompted while reading Chad Dickerson’s series of articles about RSS and the related bandwidth issue it has caused, albeit not a “crushing” issue, as Chad acknowledged in the second article, “RSS Bandwidth Blues“.

What a concept, compress webpage code and content before transferring it, in cooperation with browsers that can transparently decompress the page upon receiving it. In other words, utilize that under-used CPU power to decrease web slowdown where it’s bottleneck really exists: Bandwidth.

If you want to know more about HTTP Compression (not terribly grimy detail, just a nice overview), try this WebReference HTTP Compression article. I take exception at some of the wording about IIS on the second page in the bulleted list, however, because it says, “If it finds a pre-compressed version of a requested document it might send it but has no real-time compression capability. It will, however, use precompressed files if they are available.” This makes it sound like some special process has to be ran to compress your site’s pages before IIS can send compressed versions of the pages. But as described in Microsoft’s HTTP Compression documentation, if no compressed version of a static document is available, IIS will send the document in an uncompressed form on that first, initial request, and compress the file in the background immediately thereafter. Thus, the static document will be available in it’s compressed form on any subsequent requests, automatically. I can live with that. Further, dynamically generated documents are compressed on-the-fly. Granted, the article does explain this a little more clearly in the following paragraphs, but the introductory paragraph is very misleading.

All that being said, I’ve enabled HTTP Compression on my webserver for static documents, which is what Blogger.com uses, since it publishes the blog as HTML files every time a change is made. Cool.