One of the most commonly missed features of setting up a web server is configuring compression. All modern Browsers support both GZip and Deflate compression for content. All commercially viable web servers support GZip and Deflate compression types. IIS is no different. The reason many miss this feature is you have to configure it the way you need it to work in order for it to work. I am going to cover configuring compression in IIS 6 in this entry. I hope to follow up with some advice on IIS 7 soon.
Why Should You Compress Content
There are two primary reasons you should compress your web content, speed and bandwidth. Despite increasing the load on the CPU on the both the server and the client, compression makes a page load much faster. The reason is the content is transferred that much faster when compressed.
Saving bandwidth not only makes the site load much faster is also reduces your overall costs to operate the site. I know for my experience bandwidth is the highest cost to running any web site. Since I manage hundreds compressing content is a key factor in managing my bottom line. If you can reduce your bandwidth code by half that can be a tremendous addition to your bottom line. Think about a popular Blog, this could mean several thousand dollars a month they do not have to spend.
What Content Should I Compress
How Do I Control What Gets Compressed
In IIS 6.0 you get the option of compressing Static and Dynamic content. You can designate that only static content gets compressed if you are worried about the compression of dynamic content adding too much stress to your server. But there should be few occasions where this is an issue. Static content will get cached to the file system compressed, so it will really speed up this content. Images do not get compressed, since the image formats are already in a compress format.
There are two drawbacks to using compression in IIS, performance and global setting. Anytime you add a routine that does processing on a resource in a web server there will be processing overhead. Compression is no different, since the compression algorithm must be executed. Fortunately this performance hit is more than made up for by the added speed going down the wire. Also IIS will intelligently cache compressed documents once they are compressed the first time to serve them faster on future request. Unfortunately this gets very complicated for dynamic applications like an ASP.NET application.
One of the things I don't like is using the built-in compression service in IIS 6.0 has to be an all or nothing setting. This means that all sites on the server are compressed or none use compression, this cannot be configured for each site.
One way around this is to integrate a custom httpModule into each ASP.NET site you want to implement compression. Blowery Compression seems to be the most popular for ASP.NET platforms. There are other solutions for other application frameworks and ISAPI dlls that may also be integrated.
How to Configure IIS 6.0 Compression
This is pretty easy, open the IIS Admin Interface. Bring up the properties dialog for the Web Sites Node, not an individual site. Select the Service tab. Check the Compress Application Files and Compress Static Files checkboxes. You can then specify the folder where the temporary files will be stored. I tend to put these on another drive in order to manage space on the server better.
How to See the Difference
Well there are several tools to see the difference, but the best one is your bottom line on bandwidth costs. If you have a high traffic site you will notice the difference in the actual bandwidth used immediately. This means less overhead to your wallet.
But honestly there are some great FREE tools to help you out. The first would be Fiddler, the indispensable add-in for Internet Explorer.
This covers compression in IIS 6, I have a follow up on how to setup compression in IIS 7 soon. I think I also should follow up with a more detailed explanation about how and why compression works on the web too.