Does compressing HTTP response is useless when Content-Length is lower than 1K?_问答_开发者

Does compressing HTTP response is useless when Content-Length is lower than 1K?

开发者 https://www.devze.com 2023-02-16 23:25 出处：网络

I wrote a web service that respond JSON content lower than 1K. Which one of this compression strategy is the best?

gzip this content by the reverse-proxy as any other text ressource?
Add a rule to not compress ressources under a threshold?

I think that the packet size on internet network are greater than 1K (This 开发者_如何学Goarticle is pretty interessing but it brings me more questions than answers: 579 bytes? 1518 bytes?). This way, it would make sense to avoid taking time and processor to compress a content that will already be sent in 1 packet.

Thus I am more looking at somebody's testing about these 2 strategies? Does anybody made any test? And I am also interested in the rule you have written.

Thanks

I downloaded a copy of this page (that is, the source code containing the HTML for this question), and kept only the first 993 characters.

That is, the original size is 993 characters.

Compressing that file using gzip compression results in a file of 595 bytes.

This means that the new file is almost 60% of the original!

Conclusion: Yes, it is easily worth ~1KB of (textual) data.

Approximately halving the original size to 515 characters results in a compressed file of 397 characters, the newer file is about 77% of the original, not as good but still an advantage.

Approximately halving the file again to 223 characters results in a compressed file of 277 bytes, and the compressed file is now larger, so for very small packet sizes, gzip compression isn't useful, although it's still possible to achieve compression. (But not with a naive use of gzip).

To give you an idea of how tiny ~500 bytes is, consider google.com's response (including HTTP headers):

HTTP/1.0 302 Found
Location: http://www.google.com/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Wed, 16 Mar 2011 11:27:29 GMT
Server: sffe
Content-Length: 219
X-XSS-Protection: 1; mode=block

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

That is already 465 bytes including the header! (But the HTTP header is not normally compressed, only the content... Which here is 219 characters).

Compressing that results in a file size of 266 (excluding the headers), so is a small increase not worth worrying about.

While it may not help, compressing a small packet probably doesn't hurt either. In addition, high-concurrency systems that make use of keep-alives may still benefit, because they can potentially buffer up multiple responses in a single packet, and compression will squeeze more responses into each packet.