Using HTTP Compression Page 3

Effects on Server Performance

Compressing content obviously requires a certain amount of CPU time to compress the information for transfer. This compression process can have a detrimental effect on the site because each object selected must be compressed before sending. This is one area where IIS 6 has a leg up on Apache, as it creates a cache directory into which compressed files are kept, reducing the CPU load for frequently accessed pages. What it doesn’t do is completely eliminate the need for inline compression. Heavily dynamic content must still be compressed on the fly, and there may be a finite amount of cache storage.

To be honest, it’s unlikely that the loading in any test-heavy Web site will exceed the benefit obtained by using the compression. Savings of 50 percent in bandwidth deliver a significant site performance increase by sacrificing less than 10 percent (and often less than 1 percent) of CPU time. That’s more than worth it, especially for enterprise paying by the megabyte for transfers.

Browser Support and Dynamic Content

Today, most browsers support some kind of compression, but the exact type of compression supported is browser dependent. This is not an issue you need to worry about; the Web server will send compressed documents only if the browser indicates it supports them. It is, however, worth examining the mechanism and looking at some of the supported compression types of different browsers.

A browser supplies, as part of its URI request, the compression formats it supports through the Accept-Encoding HTTP header. Apache (and others) make this information available through the HTTP_ACCEPT_ENCODING environment variable. Again, you don’t actually need to do anything; Apache will automatically encode content appropriately if it identifies the browser can accept it through the HTTP header.

The table below lists various browsers and the encodings they support.

Browser Support for Compression Encodings

“Identity” is sometimes listed as a type. This means the browser supports uncompressed content (which is basically implied, so not all browsers explicitly state this).

As the list indicates, modern browsers support compression. Thus, clients don’t need to do anything to actually use compressed content; the browser automatically supplies its supported encodings when it makes a request. So, to get a speed improvement you need configure only the server.

Summary

Using HTTP compression is a very simple way to improve site performance and decrease bandwidth by doing very little. There are potential downsides due to the additional CPU overheads required to support it, but they are relatively minor tradeoffs in comparison to the potential benefits.

And if it doesn’t result in significant improvements? Disabling it is just as simple because the content of the site has not been modified, only the way the content is transferred.