Low Cost, High Impact Performance Tuning Should Not Be Overlooked
HTTP compression is a long-established Web standard that is only now receiving the attention it deserves. Its implementation was sketched out in HTTP/1.0 (RFC 1945) and completely specified by 1999 in HTTP/1.1 (RFC 2616 covers accept-encoding and content-encoding). Case studies conducted as early as 1997 by the WC3 proved the ability of compression to significantly reduce bandwidth usage and to improve Web performance (see their dial-up and LAN compression studies).
In the case of HTTP compression, a standard GZip or Deflate encoding method is applied to the payload of an HTTP response,
significantly compressing the resource before it is transported across the Web. GZip (RFC 1952) is a lossless compressed
data format that has been widely used in computer science for decades. The deflation algorithm used by GZip (RFC 1951)
is shared by common libraries like zip and zlib and is an open-source, patent-free variation of the LZ77 (Lempel-Ziv 1977)
algorithm. Because of the proven stability of applying compression and decompression, the technology has been supported
in all major browser implementations since early in the 4.X generation (for Internet Explorer and Netscape).
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. Whenever compression is applied, it creates two versions of a
resource: one compressed (for browsers that can handle compressed data) and one uncompressed (for browsers that cannot).
A browser needs only to accurately request which version it would like to receive. However, there are cases in which some
browsers express, in their HTTP request headers, the ability to handle a GZip compressed version of a certain MIME type
resource when they effectively cannot. These browser bugs have given rise to a number of third-party compression tools
for Microsoft IIS Web servers that give administrators the ability to properly configure their servers to handle the
exceptions necessary for each problematic browser and MIME type.
The second factor that has stunted the growth of HTTP compression is something of a historical and economic accident. Giant, pre-2001 technology budgets and lofty predictions of widespread high-bandwidth Internet connections led to some much more elaborate and expensive solutions to performance degradation due to high latency network conditions. Despite the elements being in place to safely implement HTTP compression, Akamai and other Content Distribution Networks employing edge caching technology captured the market's attention. While HTTP compression should not be viewed as a direct alternative to these more expensive options, with the help of a reliable configuration and management tool, compression should be employed as a complementary, affordable initial step towards performance enhancement.
Compression Will Deliver Smaller Web Transfer Payloads and Improved Performance
Most often, HTTP compression is implemented on the server side as a filter or module which applies the GZip algorithm to
responses as the server sends them out. Any text-based content can be compressed. In the case of purely static content, such
the burden of repeatedly compressing the same file. When truly dynamic content is compressed, it usually must be
recompressed each time it is requested (though there can be exceptions for quasi-dynamic content, given a smart enough
compression engine). This means that there is trade-off to be considered between processor utilization and payload reduction.
A highly configurable compression tool enables an administrator to adjust the trade-off point between processor utilization
and compressed resource size by setting the compression level for all resources on the Web site, thereby not wasting
CPU cycles on "over-compressing" objects which might compress just as tightly with a lower level setting as with a higher
one. This also allows for the exclusion of binary image files from HTTP compression, as most images are already optimized
when they are created in an editor such as Illustrator. Avoid the needless recompression of images as this may actually
increase their file size or introduce distortion.
Compression results in significant file size savings on text-type files. The exact percentage saved will depend on the degree
of redundancy or repetition in the character sequences in the file, but in many cases, individual files may be reduced by 70
or even 80 percent. Even relatively lumpy or less uniform text files will often shrink by 60 percent. Keep in mind that when
looking at overall savings on the site, these extremely high compression rates will be counterbalanced by the presence of
image MIME types that cannot usefully be compressed. Overall savings from compression is likely to be in the range of 30 to
40 percent for the typical Web site or application. This free online tool will help you to see the file size savings and
transfer improvement garnered from compressing any Web resource.
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
files). This free online tool will help you to gauge the bandwidth cost savings to be realized from compressing any Web
Case studies like this one from IBM have proven the performance improvement that can be realized by using compression,
especially in WAN environments that include areas of high traffic and high latency. The general principle is clear: the
more crowded the pipe and the more hops in the route, the greater the potential benefits of sending the smallest possible
payloads. When the size of the resource is drastically reduced, as a text file is when GZip compression is applied, the
number of packets sent is also reduced, decreasing the likelihood of lost packets and retransmissions. All of these benefits
of HTTP compression lead to much faster and more efficient transfers.
On Microsoft IIS 6 and 7 Web servers, httpZip
is the best solution for compression as it addresses a number of shortcomings in functionality, customization, and reporting on Windows
that gave rise to a third party tools market.