HTTP Compression: Compressing Files, How Low Can You Go?

Posted: February 23rd, 2010
Filed under: IIS & HTTP, Web Speed and Performance
Tags: , , , , , , , ,


HTTP compression on IIS is easy to enable with tools such as httpZip or ZipEnable and requires no client-side configuration to obtain benefits, making it a very smart way to get extra performance and a better user experience.

It’s well known that there is a limited amount of bandwidth on most Internet connections and anything IT administrators can do to accelerate site load time benefits not only the organization, but users as well. HTTP compression, a function built into both browsers and servers, can substantially improve site performance by reducing the amount of time required to transfer data between the server and the client. When data is encoded using a compressed format like GZip or Deflate, it introduces complexity into the HTTP request/response interaction by necessitating a type of content negotiation. This content negotiation communicates with the browser, deciding if it can or cannot handle the compressed data and sends the appropriate version of the resource to the browser.

Why use server side compression?

Most users’ knowledge of compression comes from compressed files such as .zip format that they download, extract, and open. However, compression can be used passively as well to compress documents as they are being transferred to a client’s browser. Because it’s a passive process, the server can reduce the size of the pages sent, consequently reducing the download time for users and their bandwidth usage.

You can typically reduce an HTML document to less than half of its original size, (the exact percentage saved will depend on the degree of redundancy or repetition in the character sequences in the file) saving the amount of time the client needs to download the page as well as the amount of bandwidth required. This can be accomplished without changing the way the site works, its page layout and content remain the same, the only thing that changes is the way the information is transferred between server and browser.

Keep in mind that when looking at overall savings on a site, compression rates of less than half the size may be counterbalanced by the presence of image MIME types that cannot usefully be compressed.

Acceptable File Types

Some file formats are not able to be compressed further. For instance, files that are already compressed, such as JPEGs, GIFs, PNGs, movies, and ‘packaged content’ (e.g., Zip, Gzip, and bzip2 files) are not going to compress significantly further with a simple HTTP compression filter. Therefore, you are not going to get a noticeable benefit from compressing these files.

If bandwidth savings is the primary goal, the strategy should be to compress all text-based output. Ideally, this should include not only static text files (such as HTML and CSS), but files that produce output in text media MIME types (such as ASP and ASP.NET files), as well as files that are text-based but of another media type (such as external JavaScript files). Heavily formatted pages, for example those that make heavy use of tables (repetitive formatting content) may compress even further, sometime to as little as one-third of the original size.

What tool works the best for you?

On Microsoft IIS 4 and 5 Web servers, httpZip is the best solution for compression as it addresses a number of shortcomings in functionality, customization, and reporting on Windows 2000 that gave rise to a third party tools market. httpZip is also ideal in certain cases on IIS 6.0. However, with the launch of Windows Server 2003 and IIS 6.0, Microsoft chose to make compression functionality a priority, and their internal IIS 6.0 compression software works — though you must delve into the IIS metabase to manage it beyond a simple “on/off” decision (and there is no browser compatibility checking). You should use ZipEnable to safely unlock and greatly enhance the configuration and management options for IIS 6.0 built-in compression.

/ Port80

No Comments »

Leave a Reply