HTTP compression: why fewer transferred bytes don't mean less content

Useful to know

A long text can contain many repetitions: the same words, characters, and parts of the structure. Compression uses similar patterns to present the data more compactly. In web transfer, this allows the server to send fewer bytes and the browser to recover the content. MDN distinguishes compression of the file format itself, compression of HTTP content and processing of a separate connection. These levels are related, but setting one does not automatically describe the others. [1]

The Content-Encoding header reports what conversions were applied to the resource and in what order. For example, gzip and br denote different modes of compression. Content-Type has another task: it describes the media type of the restored content. [2] Thus, a HTML document sent compressed continues to be a HTML document. The confusion between these two headers leads to erroneous conclusions, as if every compressed response should be downloaded as an archive, which the visitor manually unpacks on his computer.

Lossless compression allows for recovery of the original data. It should be distinguished from photo processing, in which some of the information consciously changes. Different file formats use different approaches, and already compressed content may not benefit from an additional general algorithm. [1] Therefore, one rule for all files is not enough explanation for good performance. Text document and photography set different tasks, even arriving through the same web service.

When set Content-Encoding, values such as Content-Length refer to the encoded form unless explicitly stated otherwise. Re-compression of an archive or JPEG can even increase the size. [2] This is useful when reading measurements: the size over the network and the size after recovery are not the same number. A smaller value does not mean missing paragraphs. It can display a more compact representation of the same data during its transfer to the client.

For our own example, we can compare a text page in two server modes. We save the content and look at the transferred volume, headers and load time. Then we repeat with an image that is already effectively encoded. Expectation doesn't have to be the same percentage saving. The measurement itself only makes sense if it is clear which resource is being compared and whether the other conditions are similar. Otherwise, a cached response or other version of the file may be mistaken for a compression result.

The practical approach starts with representative resources from the actual site. It is checked what the browser receives, and then whether the rules are applied consistently. Stronger processing also has a computing cost, so size is not the only quantity in the whole system. The goal is a well-functioning transfer for real visitors. Knowing the difference between format, encoding, and metered volume helps to evaluate settings by result, instead of just having a "compression" checkbox in the control panel.