Compression: gzip, Brotli, and What They Cost

The plain-language idea

Text-based formats — HTML, CSS, JavaScript, JSON — are highly repetitive: the same tags, keywords, whitespace patterns, and punctuation appear over and over. Compression algorithms exploit exactly that repetition. gzip is the long-established, near-universally-supported option; Brotli, newer and generally more efficient at the same or better compression ratio, is now supported by every major browser and most CDNs. Applied to text assets, either one routinely shrinks transfer size by somewhere in the range of 70-90%, which is a real, direct win for every metric that depends on bytes-over-the-wire.

That win doesn't extend to everything. Formats that are already compressed — JPEG, most video codecs, WOFF2 fonts, anything already gzipped — have already squeezed out their redundancy. Running gzip or Brotli over an already-compressed file yields little to no further size reduction, and in some cases makes the file slightly larger (compression algorithms add their own small overhead, which has nothing left to offset if there's no redundancy left to remove). Re-compressing these formats is wasted CPU work for no benefit.

See it in a real thing: where the CPU cost actually goes

Compression isn't free — it costs CPU time on both ends of the connection. The server has to spend cycles compressing the response (or serve an already-compressed version), and the client has to spend cycles decompressing it before it can use the content. For a busy server compressing every response from scratch, on every request, that's real, recurring CPU cost that competes with everything else the server is doing.

Per-request compression:  request in -> compress on the fly -> send    (repeated CPU cost, every request)
Build-time compression:   build once -> compress once -> cache -> send (CPU cost paid exactly once)

The production pattern that avoids paying that cost repeatedly: compress once, at build or deploy time, and serve the pre-compressed file from cache on every subsequent request — the server does zero compression work per request, just returns bytes that were already prepared. This is specifically why Brotli's static pre-compression at maximum quality is the recommended production practice for any asset whose contents are known at build time (your JS bundles, CSS, most HTML): compressing at Brotli's highest quality setting is genuinely slow, too slow to do live on every request, but doing it once at build time is free at request time — the cost is paid during the build, not during traffic.

What people usually miss

Watch out

• Compressing an already-compressed asset (a JPEG, an MP4, a WOFF2 font) is close to pure waste — there's little redundancy left to remove, so the CPU cost of compressing it buys almost nothing back in transfer size.
• Compression is a real cost/benefit tradeoff, not a strictly free win — it's just that for text assets, the transfer-size savings so overwhelmingly outweigh the CPU cost that it's an easy call in practice, not that the cost doesn't exist.
• "Compress at request time" and "compress at build time" are different decisions with different constraints. Static, build-time-known assets should be pre-compressed once at maximum quality; only genuinely dynamic content should pay a compression cost per request, and even then usually at a faster, lower-quality setting.
• Brotli being "generally more efficient" doesn't mean it's a strict replacement everywhere — gzip remains the safer universal fallback for the rare client or intermediary that doesn't negotiate Brotli, which is why servers typically offer both and let content negotiation pick.

Why this matters in interviews

"Your API responses are large — would you compress them?" is a real question testing whether a candidate reasons about the tradeoff (text vs. already-compressed formats, build-time vs. request-time cost) instead of reflexively answering "just gzip everything," which is wrong for the half of a typical page's payload that's already-compressed images and fonts.