HTTP Compression Speeds up the Web: WebReference.com
HTTP Compression Speeds up the Web
The volume on the Web is forecasted to more than triple over the next three years and the category expecting the fastest growth is Data. Data and Content will remain the largest percentage of Web traffic and the majority of this information is dynamic so it does not lend itself to conventional caching technologies. Issues range from Business to Consumer response and order confirmation times, to the time required to deliver business information to a road warrior using a wireless device, to the download time for rich media such as music or video. Not surprisingly, the number one complaint among Web users is lack of speed. That's where compression can help. (Update: mod_gzip, which adds GZIP content encoding to Apache, is now available)
The Solution: Compression
The idea is to compress data being sent out from your Web server, and have the browser decompress this data on the fly, thus reducing the amount of data sent and increasing the page display speed. There are two ways to compress data coming from a Web server, dynamically, and pre-compressed. Dynamic Content Acceleration compresses the data transmission data on the fly (useful for e-commerce apps, database-driven sites, etc.). Pre-compressed text based data is generated beforehand and stored on the server (.html.gz files etc).
Why Compress HTML?
HTML is used in most Web pages, and forms the framework where the rest of the page appears (images, objects, etc). Unlike images (GIF, JPEG, PNG) which are already compressed, HTML is just ASCII text, which is highly compressible. Compressing HTML can have a major impact on the performance of HTTP especially as PPP lines are being filled up with data and the only way to obtain higher performance is to reduce the number of bytes transmitted. A compressed HTML page appears to pop onto the screen, especially over slower modems.
The Last Mile Problem
The Web is as strong as its weakest link. This has and always will be the last mile to the consumer's desktop. Even with the rapid growth of residential broadband solutions the growth of narrowband users and data far exceeds its limited reach. According to Jakob Nielsen he expects the standard data transmission speed to remain at 56K until at least 2003 so there is a distinct need to do something to reduce download times. Caching data has its benefits, but only content reduction can make a significant difference in response time. It's always going to be faster to download a smaller file than a larger one.
Is Compression Built into the Browser?
Yes. Most newer browsers since 1998/1999 have been equipped to support the HTTP 1.1 standard known as "content-encoding." (although content encoding was included in the HTTP 1.0 spec: RFC 1945). Essentially the browser indicates to the server that it can accept "content encoding" and if the server is capable it will then compress the data and transmit it. The browser decompresses it and then renders the page.
Only clients that can decompress encoded content can request compressed files. Clients that do not understand compressed content request and receive the files uncompressed, thereby not benefiting from the improved download times that content encoding compliant clients can offer. Here's a list of some major browsers that support content encoding.
- Internet Explorer
- Versions 4 and above support content encoding (other than IE Mac versions 4.5/5 which do not support it).
- 5+ is HTTP 1.1 compliant by default.
Testing browsers with Hyperspace Communications online tester gives a chart like this:
Browser speed test
You can also just look at the headers your browser sends to the server, using a HTTP trace program.
To verify that Internet Explorer is configured to use the HTTP 1.1 protocol:
- Open the Internet Options property sheet
- If using IE 4, this is located under the View menu
- If using IE 5 or 6, this is located under the Tools menu
- Select the Advanced tab
- Under HTTP 1.1 settings, verify that Use HTTP 1.1 is selected (see Figure 1 below).
IE4/5 Setting HTTP 1.1
Comments are welcome
Revised: April 20, 2002