HTTP compression allows content to be compressed on the server before transmission to the client. For resources such as text this can significantly reduce the size of the response message, leading to reduced bandwidth requirements and download times.
Some content types such as zip files or gif images are already compressed and do not respond well to compression. In fact, attempting to compress them can increase the size of the response message and waste CPU time on the server.
Compression is particularly useful where secure SSL connections are used, because it reduces the amount of content that has to be encrypted on the server and decrypted by the client.
Two compression algorithms are commonly used - deflate and gzip. HTTP clients indicate their support of compression using the Accept-Encoding header as shown here:
A server will only compress content for clients that support compression and will set the Content-Encoding header so that the client knows which algorithm to use when reading the response body:
If you look at the response message for a compressed page you will see that the response headers are in clear, uncompressed text and the HTML content is in a compressed binary format:
Question: How much difference did compression* make to each of the following?
A. This Page:
The textual HTML for this page compressed well using gzip and lead to a saving of about 66% (i.e. from 12 KB to 4.2 KB)
B. Image: (smallpic.jpg)
The jpeg image is already compressed and did not benefit from compression. In fact, it increased slightly in size from 2457 bytes to 2462 bytes)
Using HttpWatch with Example 8
To view the effect of HTTP compression on this page: