What is the lower threshold to not perform http compression?

Question

When performing http compression is there low threshold where it is recommended to not perform compression?

Obviously for 100 bytes you would not compress and for 1MB you would. But are there any general recommendation on a specific low threshold?

Answer 1

IBM has a comparison, which also includes a graph. According to it there is also a benefit for compressing small files. Another, although old article describes gzip's performance as good, except for local file transfers. Although both articles are checking compressions in "dial-up" environment,

I think the question is more relevant as to what to compress, instead of how many bytes. Gzip (deflate) is usually good for textual files (html, xml, js, etc.) even if they are as small as 256 bytes, but is next to useless when compressing media files, or files that have already been compressed (like png, jar-s, docx/odt-s, etc.)

Answer 2

If you really care about it, you should compare the size differences between gzipped and uncompressed real files in your application. Start testing the smallest files you serve, and test increasing sizes. See where the gzipped size is smaller than the uncompressed, and set that to the threshold.

Unless you are Google,¹ however, it simply doesn't make much of a difference. Pick a sane value. How does 256 kilobytes sound?

---

_{¹Okay, okay... O(Google)}

Answer 3

There's not much harm in compressing short HTTP responses. They're not going to get much bigger, if at all. I'd reckon the CPU effort is always worth it if it does save bandwidth.

The better worry is the type of data. Trying to compress tight binary file types like modern image and video formats is a total waste of effort, whereas for all text content it's effective.