Two parallel HTTP/1.1 and HTTP/2 lanes both lead to gzip, separating transport choice from response-body coding.

gzip, HTTP/2, and Brotli need separate verification

HTTP/2 changes HTTP transport framing and multiplexing; gzip and Brotli encode representation data. Enabling HTTP/2 does not automatically compress response bodies, and enabling gzip does not prove that a client negotiated HTTP/2. HTTP/2 header compression is another mechanism again. A reliable check records the negotiated protocol, response Content-Encoding, transferred body size, and the bytes obtained after decoding. ...

January 28, 2028 · 6 min · XB Field Notes
The reported JSON body compresses from 28015 to 246 gzip bytes and decodes back to the exact original 28015 bytes. Shape sizes are schematic.

Enable gzip explicitly, then verify negotiation and decoded bytes

gzip is a response content coding: nginx can send a compressed representation that an accepting client decodes. Enabling it requires gzip on; gzip_types extends the eligible MIME types but does not activate compression by itself. The result depends on the response, request capabilities, and effective configuration. A smaller body is useful only if it still decodes to the intended content. ...

August 29, 2027 · 5 min · XB Field Notes
The article repeated-text fixture has 11,000 bytes, gzip content has 122 bytes, and decoding recovers the same 11,000 bytes. Counts are content bytes only, not a benchmark.

Compression negotiation is content negotiation

HTTP compression selects a coded representation, not a new media type. Gzipped text remains text after decompression. A useful check therefore asks three questions: was the coding acceptable, did the transfer become smaller, and did decoding recover the intended bytes? A compression checkbox or a successful status code cannot answer all three. ...

July 21, 2026 · 5 min · XB Field Notes