HTTP Compression by File Type: What to Measure

HTTP compression reduces response content for transfer. Whether gzip, Brotli or zstd is worthwhile depends on the actual content, compression settings and processing costs. A filename extension alone cannot provide a reliable answer.

Text formats and already compressed formats

HTML, CSS, JavaScript, JSON, XML and SVG are often good candidates. Repeated strings and other statistical patterns allow shorter representations. Minification removes whitespace or shortens names, but repeated keywords and structures remain. Minified JavaScript can therefore still shrink substantially. JSON does not necessarily consist of unique values either.

JPEG, PNG, WebP and AVIF already use compression. WOFF2 applies font-specific transformations and Brotli. Additional HTTP coding often achieves little for these formats, but may still save bytes or add overhead depending on the file. An unchanged response demonstrates a server decision, not the result of an actual second compression attempt.

SVG is XML text despite serving as an image. ICO is a container that can hold bitmap data or already compressed PNG images. Neither “every ICO is uncompressed” nor “every image is already optimally compressed” is a sound rule.

No universal hundred-byte cutoff

Small responses can also shrink. A local test on 25 October 2026 used exactly 80 ASCII a characters. gzip level 6 produced 24 bytes, Brotli level 5 produced 10 bytes and zstd level 3 produced 21 bytes. In contrast, the three input characters abc grew to 23, 7 and 16 bytes. All six outputs were decoded and compared byte for byte with the inputs.

These are artificial examples of content dependence, not website or loading-time measurements. Format implementations and settings can change the results. A server minimum-size setting is an operational tradeoff rather than a mathematical boundary for compressibility.

Format overhead also differs: gzip includes a checksum, the ordinary Brotli stream does not, and a zstd content checksum is optional. A blanket explanation involving a header and checksum in every format would therefore be incorrect.

A meaningful comparison requires identical content

1. Each variant requires the same final resource URL, relevant request conditions and measurement period. Dynamic content may change between requests.
2. Checks include HTTP status, final content type and actual Content-Encoding. Offering br does not force a Brotli response; even status 200 can contain a blocking page.
3. Complete responses require decoding and comparison byte for byte or with a suitable hash. Differing or truncated content must be excluded from size comparisons.
4. For identical content, the ratio is encoded response bytes divided by uncoded content bytes. For example, 20 KiB from 100 KiB means 20 percent remaining size or 80 percent saved.
5. Claims about speed or CPU cost require repeated runs and separate timing measurements. Precompressed static files and dynamic compression have different costs.

curl’s size_download measures downloaded payload bytes, not the complete network cost including HTTP headers, TLS and packet overhead. With --compressed, the saved file may already be decoded, making file size a different measurement. The local curl build must support the offered coding.

Cache variants and version markers

When representation selection depends on Accept-Encoding, Vary: Accept-Encoding describes that selection for caches. Checks must cover the relevant encoded and uncoded responses. A missing header can contribute to incorrect selection of reusable variants, but does not by itself demonstrate a broken page. Storage rules and other cache configuration also matter.

An ETag is a version marker sent with a response. Different encoded byte sequences require different strong ETags. A shared weak validator prefixed with W/ can identify variants with the same meaning, such as compressed and uncompressed versions of the same page, but cannot replace content checks or assessment of the intended use. Different ETag values alone do not prove a correct implementation.

What the compression checker actually shows

The Compression Negotiation Checker requests a resource sequentially using identity, gzip, br, zstd and a fixed combination. The variant labelled browser is a curl request offering gzip, deflate, br, zstd, not an actual browser measurement or a universal browser header.

The current checker reports differing decoded content but continues calculating size ratios. The decoded-body limit is 3 MiB. Such differences, truncated responses and error pages invalidate the comparison. The Vary evaluation also examines only one coded variant, while type classification does not inspect file contents. The tool provides clues rather than complete acceptance testing of a server configuration.