8. HTTP Compression

HTTP compression allows content to be compressed on the server before transmission to the client. For text based resources such as HTML, CSS, JavaScript and JSON this can significantly reduce the size of the response message, leading to reduced bandwidth requirements and download times.

Some content types, such as zip files and JPEG, PNG or WebP images, are already compressed and do not benefit from further compression. In fact, attempting to compress them can increase the size of the response message and waste CPU time on the server.

These compression algorithms are commonly used:

HTTP clients indicate which algorithms they support using the accept-encoding header as shown here:

accept-encoding: gzip, deflate, br, zstd

A server will only compress content using one of the algorithms the client supports and will set the content-encoding header so that the client knows how to decompress the response body. It also sets vary: Accept-Encoding so that caches know the response depends on that request header:

content-encoding: br
vary: Accept-Encoding

Only the content of the response is compressed in this way; the headers are not affected by content-encoding. For example, here is the response for this page, which is followed by the HTML content in a compressed binary format:

:status: 200
cache-control: no-cache, no-store
content-encoding: br
content-type: text/html; charset=utf-8
date: Tue, 13 Oct 2026 11:03:19 GMT
last-modified: Tue, 13 Oct 2026 10:01:27 GMT
server: Microsoft-IIS/10.0
vary: Accept-Encoding
x-powered-by: ASP.NET

[binary compressed HTML data starts here]

HTTP/2 and HTTP/3 also compress the headers themselves, using the HPACK and QPACK algorithms, which is particularly effective because many headers, such as user-agent and cookie, are repeated in every request.