Your edge configuration applies Brotli to every response, including JPEG and AVIF images, WOFF2 fonts and MP4 video. Which of those actually get smaller, and what does compressing the rest cost you?

## Two families of bytes For compression purposes every response you serve falls into one of two families. **Text-shaped** payloads — HTML, CSS, JavaScript, JSON, XML, plain text, and SVG — are full of repeated tokens, long identifiers and predictable structure, which is exactly what a general-purpose compressor exploits. Ratios of three to five times are routine, and minified JavaScript sits comfortably in that band. **Already-compressed containers** — JPEG, PNG, GIF, WebP, AVIF, MP4, WOFF2, and anything ending in `.zip` or `.gz` — have had format-specific compression applied at creation time, and the output of a good compressor looks close to random data to the next compressor in line. The reason is not that these formats are "binary". Gzip and Brotli operate on arbitrary bytes and will happily compress a binary file that contains redundancy. The reason is that the redundancy is already gone: PNG applies DEFLATE to its pixel data, GIF uses LZW, JPEG and AVIF and MP4 use their own domain-specific coding, and WOFF2 compresses its font tables with Brotli as part of the format definition. Compressing those again finds essentially nothing to exploit. ## What compressing them anyway costs The saving is roughly zero; the cost is not. **CPU per response.** On-the-fly compression runs on every cache miss, and Brotli in particular is asymmetric: decoding is cheap, encoding at high quality is expensive. Spending that budget on a 4 MB video segment that will not shrink is CPU you cannot spend compressing the HTML harder, and under load it turns into queueing that users experience as slower time to first byte. **Latency on large responses.** A compressor has to work through the bytes before output can flow, so for large payloads on-the-fly compression can add delay to a response that would otherwise have started streaming immediately — a bad trade when the outcome is a saving of a fraction of a percent. **Operational noise.** Compressed variants are stored and served per encoding, so blanket compression multiplies stored variants at the edge for asset classes that gain nothing from having them. Hence the standard shape of a correct configuration: an explicit MIME-type allowlist of text-shaped types, plus a **minimum size threshold** — very small responses of a few hundred bytes are not worth compressing at all, because the ratio on tiny inputs is poor and the per-response overhead outweighs the win. ## The two mistakes teams actually make In practice, over-compression wastes CPU quietly while **under-compression wastes bandwidth quietly**, and the second is more damaging. The classic misses: - **SVG.** It is served with an image-flavoured content type, so it falls off allowlists built by thinking "images are already compressed". SVG is XML — an icon sprite or illustration frequently compresses by 70% or more. Always compress it. - **JSON API responses.** Dynamic endpoints on a different origin or behind a different proxy often miss the config the static site got. Repetitive JSON compresses extremely well, and on a data-heavy screen it is the largest text payload on the page. - **Assets on a second origin.** A storage bucket or a legacy host serving your CSS and JS may default to no compression at all. This is invisible unless you check. - **Web manifests, plain-text and source-map-adjacent files** for the same allowlist reason. The check is cheap: request an asset with and without an accepted encoding and compare sizes. ```bash for u in https://example.com/app.css https://example.com/icons.svg https://example.com/hero.jpg; do raw=$(curl -s "$u" | wc -c) br=$(curl -sH 'Accept-Encoding: br' "$u" | wc -c) echo "$u raw=$raw br=$br" done ``` Identical numbers on a text asset mean it is not being compressed. Near-identical numbers on the JPEG are the expected, correct outcome. ## Static versus dynamic The same allowlist reasoning applies to build outputs, with one extra lever: compression work you do once at build time can afford a much higher quality setting than work you do per request, because nobody is waiting on it. That is precisely why the analysis matters — you want that expensive, one-time effort spent on your text assets and never spent on your media. ## The answer in one line Compress by content shape, not by reflex. Text yes, already-compressed containers no, SVG and JSON emphatically yes, small responses not worth it — and verify what is actually happening on the wire rather than trusting the configuration to mean what it says.