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).

The goal is to send less data. To do this the data must be analyzed and compressed in real time and be decompressed with no user interaction at the other end. Since smaller amounts of data (less packets) are being sent, they consume less bandwidth and arrive significantly faster. The network acceleration solutions need to be focused on the formats utilized for data and content including HTML, XML, CSS, Java, JavaScript, WML and all other text based languages. Both types of compression utilize HTTP compression and compress HTML files fully three times smaller.

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).

Netscape

Versions 4.06-4.08 support content encoding but can be buggy. Netscape 4.5 is the only browser that supports gzip encoding for HTML files even though it communicates via HTTP/1.0. However, Netscape 4.x still sometimes fails to decompress gzipped CSS and JavaScript when referenced via separate HTTP calls (embedded in HTML they are okay), so some webmasters have excluded either those MIME types or Netscape 4 from compression (mod_gzip doesn't allow you to "AND" both conditions). Netscape 6 (Mozilla) supports HTTP 1.1, although earlier versions of Netscape 6 can be buggy in regards to content encoding.

Opera

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:

1. 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
2. Select the Advanced tab
3. Under HTTP 1.1 settings, verify that Use HTTP 1.1 is selected (see Figure 1 below).

IE4/5 Setting HTTP 1.1

Next page, What is HTTP Compression?

Comments are welcome