Text compression, and the responses that miss out

Almost nobody has compression switched off entirely. What sites have is a gap, and the gaps are predictable.

• A type list that has not been updated. The server compresses a named set of content types, and anything outside the list is served raw. The list was written before application/json, image/svg+xml and application/manifest+json mattered.
• A minimum size threshold set too high. Reasonable in principle, since compressing 200 bytes costs more than it saves. Set at 20KB it excludes most of your CSS and every API response.
• A proxy that strips the header. The origin compresses, something in the middle decompresses to inspect and forgets to recompress. This is the hardest one to diagnose because the configuration you are looking at is correct.
• Assets on a different host. Your pages come from a CDN with compression on, your uploads come from object storage with nothing configured, and the second is where the volume is.
• Responses that opt out. Streamed responses, server-sent events and anything that sets its own encoding. Sometimes deliberate, and worth knowing which of yours are.

The pattern to notice: every one of these produces a site where the home page is compressed and something else is not. Testing one URL and concluding the site is fine is the mistake this check exists to correct.

Indirectly, through the same mechanism as everything about delivery: what arrives, and how quickly. Nothing reads whether a response was compressed, and no assessment of your content is affected by the encoding it travelled in.

There is one specific consequence worth naming. Clients that fetch pages programmatically often operate under a timeout, and some of them under a size limit. A large uncompressed document is slower to transfer and closer to whatever ceiling the client has, which makes a truncated or abandoned fetch marginally more likely. That is a real effect at the tail rather than a general one.

The honest position: compress your text because it makes your site faster for people and cheaper to serve. The machine-reader argument is a rounding error next to those two, and presenting it as more would be inventing a mechanism.

One function, run against the URLs that carry your weight: a page, a stylesheet, a bundle, an SVG, an API response.

ratio() {
  raw=$(curl -s -o /dev/null -H 'Accept-Encoding: identity' -w '%{size_download}' "$1")
  br=$(curl -s -o /dev/null -H 'Accept-Encoding: br, gzip' -w '%{size_download}' "$1")
  enc=$(curl -s -I -H 'Accept-Encoding: br, gzip' "$1" \
    | grep -i '^content-encoding:' | cut -d' ' -f2 | tr -d '\r')

  if [ "$raw" -gt 0 ] 2>/dev/null; then
    printf '%-46s %7s -> %7s  %3s%%  %s\n' \
      "$1" "$raw" "$br" "$(( 100 - br * 100 / raw ))" "${enc:-NONE}"
  fi
}

ratio https://example.com/
ratio https://example.com/assets/app.css
ratio https://example.com/assets/app.js
ratio https://example.com/icons/logo.svg
ratio https://example.com/api/products
ratio https://example.com/sitemap.xml

A saving near zero with an encoding of NONE is an uncompressed response. Read the list rather than the first row: the interesting output is almost always the SVG or the API endpoint rather than the page, because the page is the one somebody checked when they configured this.