5

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?

| improve this question | | | | |
  • 1
    "What is the maximum size..." - but the rest of your question is discussing "very small documents"? – MrWhite Feb 13 '16 at 7:38
  • I was confused by that too, @w3dk. I edited "maximum" out of the question. – Stephen Ostermiller Feb 13 '16 at 20:48
4

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.

| improve this answer | | | | |
4

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.

| improve this answer | | | | |
  • The 1400 bytes point is missed by many people. – Rob Feb 14 '16 at 14:53
  • there are 2 issues with this answer: 1. gzip_static ignores gzip_min_length and will serve the gz file however big it is. the answer does not make this exception clear. 2. yes, smallest ethernet MTU is 1400 bytes. however nginx takes the "length" from the http response's Content-Length header which does not include the size of the header fields. In http 1.1 the headers are not compressed, so if the page is heavy on headers, even a tiny gzipped bodied response might spill over into multiple ethernet frames. – minusf Oct 23 '19 at 9:53
  • @minusf Thanks, that information is helpful. Please edit my answer if you think it can be improved, or post a new one if you prefer a complete rewrite. – Tom Brossman Oct 24 '19 at 10:59
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.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.