How Much Can You Save With HTTP Compression?

I have added a new tool to my online toolbox which helps answer this very question. What it does is take a URL, download the page and analyze the gain from compression. If the page is already served compressed, it decompresses it and then repacks with gzip and various levels of deflate. Interestingly enough, the difference isn’t that huge and stays within 3%.

I have to hide behind a disclaimer, though: the tool does not measure the total size of a page, but only the raw HTML of the inspected page. A browser would download images, media files, external JavaScript, style sheets, which in their turn can import other style sheets, and so forth. You’d pretty much have to write your own browser to chase down everything.

A question of whether it’s safe to compress JavaScript and CSS comes up all the time. In the browser zoo that we have to deal with there’s only empirical data, which shows it’s not 100% safe to do so. Older browsers—both Netscape and Internet Explorer—created a mess misreporting supported compression algorithms, inability to handle compressed external JavaScipt files, etc. My choice is to steer clear of JavaScript and CSS compression. Browsers cache them anyway, so I don’t worry about them being downloaded all the time.

As I mentioned in an earlier post on this subject, Run, Run As Fast As You Can, compression doesn’t come for free, but even with the weakest level of deflate you still save a ton. Network transfers are comparatively slow, so the small perf hit you take compressing is worth it.

It is also important to emphasize that a page is compressed on the server and subsequently decompressed by the browser on the client. It doesn’t happen the other way around—as nice as it would have been—so compression helps you only this much.