Compress Your Content
Posted on 2007-11-10 (Updated on 2019-01-22)
"My, loading that web site was entirely too fast for my tastes. I wish the authors of this page would slow it down a bit!"
Never in the history of computing will you ever hear the statement above spoken out loud - well, at least not seriously. When it comes to load time, there's no such thing as too fast, and your visitors will thank you if you embrace that concept.
So... what is a conscientious web developer to do?
Next to good design practices, HTTP compression is one of the best tools we have to save our visitor's time. This technology works at the server level, so if you use a web host, you'll have to talk to them.
The way it works, without getting too technical, is a lot like creating a ZIP archive. Each bit of information (with a few exceptions), gets sent through a compression mechanism if the other side supports it. You use up much less bandwidth than you normally would, and all it costs you is a little processor time. Since your processor time is almost always cheaper and more abundant than bandwidth, this is a win-win situation - and all of your pages load much faster as a result.
Now, the drawbacks. HTTP compression works fantastically on text, like static HTML documents and dynamically generated pages (like ASP.net and PHP). With everything else, it's hit or miss. For instance, I'm under the impression that Javascript and CSS files should not be compressed. The browser needs to get these files as fast as possible to render your page correctly, and adding another step (decompression) in-between receiving the file and rendering your page could cause some display problems. A flash of unstyled content could result, and that might not be acceptable.
In addition, you shouldn't compress files that are already compressed. Compressing information more than once can lead to data loss... I think. I'm speaking from information gathered ten years ago, but I believe the basic concepts haven't changed much. Also, compressing content that's already been compressed, like re-ZIPing a ZIP file, takes a long time to process and doesn't gain you that much.
Now, certain file formats (Flash, PDF, OpenDocument, images, etc.) already come compressed, so you shouldn't use HTTP compression on those. Everything else is fair game, as long as you look into the file formats.
Give HTTP compression some thought, it'll help you save on bandwidth expenses and help you save your visitors some time as well.