Notes on HTTP compression in IIS 6.0

Enabling HTTP compression in IIS 6.0 provides faster transmission times between IIS and compression-enabled browsers

Compression-enabled browsers typically send the following header if they are compression-enabled: Accept-Encoding: gzip, deflate.

HTTP compression can be beneficial unless processor usage is already very high. If the % Processor Time counter is already 80 percent or higher, enabling HTTP compression is not recommended.

You can compress static files and application response files. Compressing application response files is usually called dynamic compression.

When the CPU of your server is not heavily loaded, the simplest compression strategy is to enable static and dynamic compression for all of the sites and site elements (directories and files) on the server.


Scott Forsyth has an interesting step by step article on HTTP Compression in IIS 6.0. In it he also talks about how to disable or enable compression at the site, sub-folder and file level. [Screenshots]

XCompress uses patent-pending smart compression technology to ensure that end users receive optimized responses regardless of their browser type or the type of content they are requesting.

Firefox uses HTTP 1.1 and supports compressed pages. IE 6 sends the header Accept-Encoding: gzip, deflate only when using HTTP 1.1. Fiddler can be used to inspect the HTTP headers.

In IE as PDF documents fail when transferred in compressed form, the HTTP Compression feature for dynamically generated PDFs or similar files should be avoided or done only after adequate testing.

You can quick test a site for gzip encoding at Leknor

Also see:
"There was an error opening the document; the file does not exist"

Comments