Should I compress very small HTML pages?

Question

Here's the thing:

More compression of a page means more work of the server CPU. 99% of my website for most visitors is gzip compressed.

I have made error pages which are not compressed. They use 2 KB. At first I thought about compressing them so they're 1 KB or less while maintaining HTML structure but I'm not sure if this is a good idea.

I'm actually not sure what approach to take with compressing very small documents because if I compress them then the server might be spending too much CPU power on script kiddies and this can increase the time to first byte for loading new pages. If I don't use compression, then I'll be using more bandwidth. All in all, I'm trying to make my site faster for everyone.

So my question then is What is the smallest size my HTML document can be before compression becomes overkill?

Answer 1

To answer your specific question, the smallest size an HTML document (or any page asset like CSS or JavaScript) can be before compression becomes overkill will be what you can fit inside a single TCP packet. This is the Maximum Transmission Unit or 'MTU', and a safe assumption about size is 1400 bytes. Compressing assets smaller than 1400 bytes is pointless.

Nginx has the ability to set a minimum size with its gzip_min_length module. It can also serve pre-gzipped content if you want to do that step ahead of time, but you have to tell it to with the gzip_static module. For Nginx, you would add or edit the following into the relevant server blocks:

gzip_min_length 1400;
gzip_static on;

For Apache, I'm not aware of any minimum size setting but mod_deflate can be instructed to serve precompressed content as well.

One last note, the HTML5 Boilerplate team have some great configuration examples in their GitHub repository, for example see this Apache configuration for file compression. It's a great resource and very well commented so you can adapt it to your needs.

Answer 2

Enabling compression is almost universally a good idea. You might not save much data on very small pages, but you also won't waste very much CPU compressing them.

An even better idea, if you're trying to ensure your site is fast and reliable, is to put a caching service like CloudFlare between your users and your server. Having a good intermediary will help keep your site up during heavy load, mitigate DoS attacks, and other benefits.

Answer 3

It's a good question and there is no one size fits all answer. However with the rise of mobile networks the answer is almost always compress as much as possible. In the long run uncompressing on the client will always use less energy than using more bandwith.

Gzip is very lightweight but it can become an overkill when:

• the compression level is set to too high (> 6)

• the content is already compressed well enough: don't compress a jpeg for example.

• the size of the content is "too small". The nginx gzip_min_length parameter is based only on the body of the response, headers excluded. It's a bit misleading and even if the size of the MTU was known, it would be not a good value for it. The default of 20 bytes is probably a bit too small, the HTML5 boilerplate project recommends 256 bytes...

Of course for all the content that could be pre-compressed, gzip_static is a very good solution, however it's an extra module that needs to be installed and it needs extra storage. Last but not least it complicates the publishing/deploying pipeline.