: Should I compress very small HTML pages? 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

@Shakeerah822

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.

Vote Up Vote Down

@Vandalay111

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.

Vote Up Vote Down