Compression is the rare optimization with no user-side trade-off — smaller responses are simply better — which is why it's configured carelessly: defaults on, levels unexamined, precompression unused. This guide sets it deliberately: what to compress, the two-track level strategy, how variants interact with your cache, where Zstandard actually stands in 2026, and the two failure modes to check for.
What to compress — and what never to
Compression applies to text-shaped bytes: HTML, CSS, JS, JSON, SVG, XML, fonts in their raw forms — routinely 60–85% smaller under Brotli, the single largest byte reduction available per response. It must not apply to already-compressed formats: JPEG, WebP, AVIF, video, audio, ZIPs, WOFF2 (which is internally Brotli-compressed already) — recompressing them burns CPU to add bytes. Configure the boundary by content type allowlist at the edge, and fix the origin's MIME hygiene first: mislabeled responses (application/octet-stream on what is actually JSON) silently fall outside the allowlist and ship uncompressed forever. A minimum-size floor (skip responses under ~1 KB, where headers dominate and compression can grow the payload) completes the boundary. This section is five minutes of configuration; the audit in section five is what makes it stick.
The two-track level strategy
Compression levels trade CPU time for bytes, and the correct level depends entirely on how many times the work is amortized. Dynamic responses — compressed once, served once — want moderate levels: Brotli around 4–6 and gzip around 6 sit at the efficiency knee, capturing most of the ratio at a fraction of the top-level CPU; Brotli 11 on per-request HTML is latency you're charging every user for single-digit-percent extra savings. Static assets — compressed once, served millions of times — want maximum levels, achieved by precompressing at build time: emit .br (Brotli 11) and .gz (gzip 9 or zopfli) variants alongside each hashed asset, and let the origin or edge serve the precompressed file directly. Build minutes are free at request time, which makes precompression the highest-ratio compression available at zero serving cost — the natural companion to the versioning pipeline from the asset guide. Where the CDN compresses on your behalf, check whether it honors origin-precompressed variants or insists on its own pass, and at what level.
Compressed variants and your cache
Each encoding is a distinct response variant, and how variants meet your cache decides whether compression multiplies entries. The standards answer is Vary: Accept-Encoding — legitimate and low-cardinality after normalization, per the Vary guide — and modern platforms go further, normalizing the wild's messy Accept-Encoding headers to a small set of variant slots and often storing one canonical compressed form, transcoding at the edge for the rare client that needs another. The configuration questions to answer on your platform: does the edge compress cached content itself or only pass through origin encoding; are variants stored per-encoding (multiplying storage but not misses) or canonically; and does a purge remove all variants together (it should — verify once). Get these three answers from your platform's docs and your setup stops being folklore.
Zstandard in 2026: where it actually stands
Zstandard reached the browsers — Chromium and Firefox advertise zstd — and its decompression speed at Brotli-class ratios makes it the technically interesting successor. Edge reality is narrower: Cloudflare is the notable major serving it (with plan-dependent default encodings across its tiers), while CloudFront and most of the rest of the field haven't shipped it — the platform-by-platform state lives in our compression support matrix. The practical posture for most estates: configure the negotiation ladder as zstd-if-available, Brotli as the workhorse, gzip as the floor, and let clients and edges meet where they can — you inherit Zstandard's wins wherever the pair supports it without betting anything on it. Revisit annually; compression transitions move at the pace of the slowest popular middlebox.
The two failure modes to check
Compression fails in two quiet ways, both findable in an afternoon. Non-compression: responses that should be compressed shipping raw — mislabeled MIME types, an origin behind a proxy that strips Accept-Encoding, a CDN rule scoped to the wrong paths. Detect from edge logs: text-type responses above your size floor with no Content-Encoding, grouped by path — each group is a finding. Double-compression: a compressed origin response compressed again, or compressed bytes stored and then wrapped once more — visible as Content-Encoding anomalies or as clients receiving garbage; it usually enters through an origin middleware added while edge compression was already on. Decide once who compresses (edge preferred for dynamic, origin/build for precompressed static), disable the other layer explicitly, and add both checks to the quarterly audit alongside the byte-hit-ratio review from the measurement guide — compressed bytes are the cheapest bytes you'll ever not send.