Payload Compression Trade-off
The exchange of CPU time for reduced transfer time, which is favourable on constrained networks and harmful on fast local ones.
Compression is not free and is not always a win. The calculation is compression time + transmission of the smaller payload versus transmission of the original.
On a mobile network with limited bandwidth and high latency, compressing a 500 KB JSON response to 50 KB is a large gain. Between two services in the same availability zone on a 10 Gbps link, the CPU cost can exceed the transfer saving — particularly at high request rates, where compression becomes a measurable share of total CPU.
Algorithm choice reflects the same trade: gzip is universal and moderate; Brotli compresses text better at higher CPU cost, and is well suited to static assets compressed once and served many times; zstd offers a wide, tunable range and is often the best default for internal service traffic; Snappy and LZ4 prioritise speed over ratio, which is why they dominate in storage and streaming systems.
Details that matter: already-compressed content (images, video, archives) should be excluded, since compressing it wastes CPU for nothing; very small payloads can grow; and compression before encryption is standard, with the caveat that combining the two on attacker-influenced content has historically enabled side-channel attacks.