Category: Web Compression

HTTP Compression – Have you checked ALL your browsers?

2012-09-25 / spierzchala / 0 Comments

Apache has been my web server of choice for more than a decade. It was one of the first things I learned to compile and manage properly on linux, so I have a great affinity for it. However, there are still a few gotchas that are out there that make me grateful that I still know my way around the httpd.conf file.

HTTP compression is something I have advocated for a long time (just Googled my name and compression – I wrote some of that stuff?) as just basic common sense.
Make Stuff Smaller. Go Faster. Cost Less Bandwidth. Lower CDN Charges. [Ok, I can’t be sure of the last one.]

But, browsers haven’t always played nice. At least up until about 2008. After then, I can be pretty safe in saying that even the most brain-damaged web and mobile browsers could handle pretty much any compressed content we threw at them.

Oh, Apache! But where were you? There is an old rule that is still out there, buried deep in the httpd.conf file that can shoot you. I actually caught it yesterday when looking at a site using IE8 and Firefox 8 measurement agents at work. Firefox was about 570K while IE was nearly 980K. Turns out that server was not compressing CSS and JS files sent to IE due to this little gem:

 BrowserMatch \bMSIE !no-gzip gzip-only-text/html

This was in response to some issues with HTTP Compression in IE 5 and early versions of IE6 – remember them? – and was appropriate then. Guess what? If you still have this buried in your Apache configuration (or any web server or hardware device that does compression for you), break out the chisels: it’s likely your httpd.conf file hasn’t been touched since the stone age.

Take. It. Out. NOW!

Your site shouldn’t see traffic from any browsers that don’t support compression (unless they’re robots and then, oh well!) so having rules that might accidentally deny compression might cause troubles. Turn the old security ACL rule around for HTTP compression:

Allow everything, then explicitly disable compression.

That should help prevent any accidents. Or higher bandwidth bills due to IE traffic.

HTTP Compression and Web 2.0

2005-07-11 / spierzchala / 0 Comments

HTTP Compression is a well-acknowledged way to improve Web performance and decrease bandwidth usage by compressing text content before transmitting it to the client. This has become an increasingly interesting topic for Web 2.0 sites starting to experience their first growth pains.

COMPANY	COMPRESSION
Technorati	NO
Flickr	NO
Wikipedia	YES
Blogger	YES
Feedster	NO
Bloglines	YES
Gizmodo	YES
TypePad	YES
Weblogs INC	NO
Scripting News	NO
Memeorandum	NO

The sample above is far from representative. However, I would have thought that companies leading the Web 2.0 revolution would be learning the Web performance lessons of the previous generation.

All data was gathered using the GrabPERF Monitoring System

Performance Improvement From Caching and Compression

2005-04-30 / spierzchala / 0 Comments

This paper is an extension of the work done for another article that highlighted the performance benefits of retrieving uncompressed and compressed objects directly from the origin server. I wanted to add a proxy server into the stream and determine if proxy servers helped improve the performance of object downloads, and by how much.

Using the same series of objects in the original compression article^[1], the CURL tests were re-run 3 times:

Directly from the origin server
Through the proxy server, to load the files into cache
Through the proxy server, to avoid retrieving files from the origin.^[2]

eries of three tests was repeated twice: once for the uncompressed files, and then for the compressed objects.^[3]
As can be seen clearly in the plots below, compression caused web page download times to improve greatly, when the objects were retrieved from the source. However, the performance difference between compressed and uncompressed data all but disappears when retrieving objects from a proxy server on a corporate LAN.

Instead of the linear growth between object size and download time seen in both of the retrieval tests that used the origin server (Source and Proxy Load data), the Proxy Draw data clearly shows the benefits that accrue when a proxy server is added to a network to assist with serving HTTP traffic.

Uncompressed Pages

	MEAN DOWNLOAD TIME
Total Time Uncompressed — No Proxy	0.256
Total Time Uncompressed — Proxy Load	0.254
Total Time Uncompressed — Proxy Draw	0.110

Compressed Pages

	MEAN DOWNLOAD TIME
Total Time Compressed — No Proxy	0.181
Total Time Compressed — Proxy Load	0.140
Total Time Compressed — Proxy Draw	0.104

The data above shows just how much of an improvement is gained by adding a local proxy server, explicit caching descriptions and compression can add to a Web site. For sites that do force a great of requests to be returned directly to the origin server, compression will be of great help in reducing bandwidth costs and improving performance. However, by allowing pages to be cached in local proxy servers, the difference between compressed and uncompressed pages vanishes.

Conclusion

Compression is a very good start when attempting to optimize performance. The addition of explicit caching messages in server responses which allow proxy servers to serve cached data to clients on remote local LANs can improve performance to even a greater extent than compression can. These two should be used together to improve the overall performance of Web sites.

[1] The test set was made up of the 1952 HTML files located in the top directory of the Linux Documentation Project HTML archive.
[2] All of the pages in these tests announced the following server response header indicating its cacheability: Cache-Control: max-age=3600
[3] A note on the compressed files: all compression was performed dynamically by mod_gzip for Apache/1.3.27.