Its a well known fact that Using HTTP Compression for Faster Downloads makes good sense. Also, if you have any problems getting this to work then Troubleshooting HTTP Compression in IIS6 is a good place to start.

This is just a little ‘note to self’ about using the IIS Metabase Explorer to configure your web server for compression, specifically at a site level. My situation arose because the IT guys didn’t want to apply compression across every site on the server, if it wasn’t necessary. I was using the Metabase Explorer to change my IIS settings and having configure the HcDoDynamicCompression, HcDoDynamicCompressionLevel and HcScriptFileExtensions records for defalte and gzip keys, I went to set the DoDynamicCompression record for the site.

After creating the DoDynamicCompression record on the root node for the site and changed the value to 1 (true) I went to check the response from the server. To my surprise the response still wasn’t being compressed. After a bit of head scratching I deleted the DoDynamicCompression record and then re-added it, this time using the adsutil IIS admin script. After checking the response and finding it was now compressed successfully I went back to the Metabase Explorer to see what was different.

For site level compression there are a couple of additional values that need setting for the DoDynamicCompression record:

1. The User Type needs to be changed to File.
2. The Attributes need to be set to Inheritable.