The topic du jour for the ASP.NET developer blogging community seems to be HTTP compression. HTTP compression involves the Web server compressing its HTTP response message using any one of a number of standard compression routines. This compressed message is then transmitted to the requesting client where the client decompresses it and then does whatever it wanted to do with the data (display it in a browser, save it as a file, etc.).
When a Web browser makes a request to a Web server it can send along an Accept-Encoding header with a comma-delimited list of compression types accepted (the common ones being gzip and deflate). The Web server, then, can then compress the response on the fly for these compression-aware Web browsers. The cost of compression is a bit of extra processing time at the server and client to compress and decompress, respectively. The benefit is in the decreased payload leaving the Web server, meaning the Web site's overall bandwidth is less and the data gets to the client sooner, which can be noticeably sooner for broadband-challenged visitors. Compression of HTML documents can range based on the degree of compression used, and the compressibility of the data. I've seen companies and individuals tout numbers ranging from 20% to 60%. For example, James Avery noted a 45% savings by enabling compression on IIS. (For a more in-depth discussion of HTTP compression, be sure to read: HTTP Compression Speeds Up the Web.)
So how does one go about enabling compression on their Web server? There are third-party products that will fit the bill, PipeBoost and XCompress being two such products. With Windows 2003 Server and IIS 6.0, IIS natively supports HTTP compression. To learn how to configure IIS 6.0 for compression, be sure to read Scott Forsyth's IIS Compression in IIS 6.0 article, as well as Brad Wilson's article IIS 6 Compression and ASP.NET.
If you do not have access to your Web server, or you are not running IIS 6.0, you can still benefit from compression by using a custom ASP.NET HTTP module. Ben Lowery has created a free HttpCompressionModule class that you can download and start using in your ASP.NET applications. For example, Jeff Julian has integrated Ben's compression module with .Text, the blogging software used to run this blog and many others. Specifically, Jeff's modification of .Text uses compression just on the RSS syndication feed (Rss.aspx), since this is typically the most requested file and is responsible for the majority of bandwidth used on a .Text Web site by far...
When visiting a Web site with compression enabled, the end user cannot determine if compression is used or not. That's how it should behave, after all - everything should work just as it normally would. For more savvy end users, though, there is a means by which one can tell if the page they are viewing was sent over the wire as compressed data or not. The simplest way is to inspect the HTTP response headers. In Mozilla Firebird this is as easy as downloading Live HTTP Headers extension. Look for a Content-Encoding header that has a value like gzip or deflate. This would indicate that the content was encoded using a particular compression algorithm. Another approach is to download a packet sniffer like Ethereal and capture the packets requested from the Web site. When inspecting the payload you'll see the HTML content looks like a bunch of goobledygook - this is the compressed data.