gzip, Brotli and zstd: HTTP Compression Measured

HTTP compression reduces the bytes needed to transfer a response body. The result depends on the content, compression settings and the response actually returned. A successful HTTP status alone does not prove that the requested homepage arrived.

A check of twenty domains on 24 October 2026 produced seventeen regular HTML responses and three access-block responses. Of the seventeen regular responses, eleven used gzip, five used Brotli and one had no Content-Encoding. No response selected zstd. These are observations from one request configuration, not market shares or permanent website settings.

How the response encoding is selected

Accept-Encoding advertises acceptable response encodings. The sample offered gzip, deflate, br, zstd with equal default weights. Server capabilities, configuration and resource type influence the selection; the order of this list is not a guaranteed preference order. An unencoded response is normally acceptable unless explicitly excluded.

Content-Encoding identifies the encoding actually applied. Absence of the field means no content coding is declared, not that the body must match a file on disk. HTML can be generated dynamically. Encodings can also be stacked; decoding then reverses the listed application order.

When the representation varies with this request field, Vary: Accept-Encoding helps compliant caches keep variants separate. The header is not proof that every intermediary is configured correctly. Cached or precompressed responses can be selected without recompressing the content for every request.

gzip, Brotli, zstd and deflate

• gzip: widely supported, but not guaranteed in every client or tool build. The advertised capabilities still matter.
• Brotli (br): often effective for text. Quality settings trade encoding effort against output size; no fixed speed or size advantage applies to every input.
• Zstandard (zstd): designed for a useful speed-to-compression trade-off. Results depend on level, implementation, hardware and data. Zero selections in this sample do not imply missing browser support or universal server non-support.
• deflate: the HTTP coding uses a zlib wrapper around DEFLATE. gzip also commonly uses DEFLATE, with a different wrapper. The formats are not interchangeable.

Actual browser offers depend on browser version and context. A manually constructed curl request is not a browser compatibility test.

The measured responses

The measurement ran from a Raspberry Pi between 04:45:33 and 04:45:37 UTC on 24 October 2026. curl 8.14.1 supported all four offered decoders. Each domain received one retrieval chain, with HTTPS redirects followed, no login or browser JavaScript, and the default curl user agent. The table describes the final response. Headers, decoded bodies and curl metadata were retained for verification.

New York Times and ZEIT returned HTTP 403. Microsoft returned HTTP 200 but an explicit access-block page. Those three responses are excluded from the regular-homepage totals. The Microsoft body contained 201,253 bytes with no declared content coding; this does not establish the compression policy of the actual Microsoft homepage.

Python.org returned regular homepage HTML without Content-Encoding in this run. A no-JavaScript notice occurs inside that homepage; the notice alone is not a separate access-block page. Earlier or differently configured requests can receive another representation.

Ratio and saving are different numbers

The ratio is decoded body bytes divided by encoded body bytes. A ratio of 4 means the encoded body is one quarter of the decoded size: a 75% reduction. It does not mean a fourfold improvement in page-load speed.

Among the compressed regular responses, the ratios ranged from 2.93 at nginx.org to 12.56 at tagesschau.de. For tagesschau.de, 1,613,994 decoded bytes corresponded to 128,481 encoded bytes, about 92.0% fewer body bytes. These numbers exclude response headers, TLS and transport framing, other page resources and rendering work.

Different websites provide different inputs, so these ratios cannot rank the algorithms. A fair algorithm comparison compresses identical bytes at documented settings and measures CPU time as well as size. Repetition, not simply file length or use of a framework, determines how much redundancy is available.

A measurement needs matching bodies

Comparing two separate requests can mix different content, redirects, error pages or cache variants. An identity request also needs its actual Content-Encoding checked. Comparing the transferred and decoded sizes of the same response avoids mixing different content, but still requires a complete successful transfer, correct decoding and content inspection.

In this measurement, curl used --compressed: the saved body was decoded, while size_download recorded transferred body bytes. Saved response headers still describe the encoding on the response. The saved file must therefore not be decoded again merely because those headers contain gzip.

curl -q --fail --silent --show-error --max-time 30 --max-filesize 10000000 --proto "=https" -H "Accept-Encoding: gzip" -D headers.txt -o body.bin -w "%{http_code}\n" https://example.com/

gzip -t body.bin &&
gzip -dc body.bin > decoded.html &&
wc -c body.bin decoded.html