Figure 9-8. File size savings in HTTP compression

Chapter 9 - Advanced Web Performance Optimization

Browsers and servers have brief conversations regarding what they would like to receive and send. Using HTTP headers, they zip messages back and forth over the ether with their content shopping lists. A compression-aware browser tells servers that it would prefer to receive encoded content with a message in an HTTP header like this:

REQUEST
GET / HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Host: www.webcompression.org
Connection: Keep-Alive

An HTTP 1.1-compliant server would then deliver the requested document by using an encoding that is acceptable to the client. Here’s a sample response from WebCompression.org:

RESPONSE
HTTP/1.1 200 OK
Date: Sun, 06 Apr 2008 22:38:00 GMT
Server: Apache
X-Powered-By: PHP
Cache-Control: max-age=300

Expires: Sun, 06 Apr 2008 22:38:00 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 1168
Keep-Alive: timeout=15
Connection: Keep-Alive
Content-Type: text/html; charset=ISO-8859-1

Now the client knows that the server supports gzip content encoding, and it also knows the size of the file is 1,168 bytes (Content-Length). The client downloads the compressed file, decompresses it, and displays the page. Without gzip compression, the home page HTML of WebCompression.org would be 3,183 bytes, about 2.7 times larger in file size (see Figure 9-8).

file size savings with http compression

Figure 9-8. File size savings in HTTP compression (from Port80Software.com tool)