One of the easiest performance wins on the web is also one of the most overlooked: compressing responses before sending them. Enabling compression can cut the size of text-based assets by seventy percent or more, with almost no downside. This guide explains how it works and how to make sure you are getting it.
Why text compresses so well
HTML, CSS, JavaScript and JSON are full of repetition — repeated tags, property names, whitespace and common words. Compression algorithms exploit that redundancy, replacing repeated sequences with short references. Because text is so repetitive, the savings are large; binary formats like images, which are already compressed, gain little.
Gzip and Brotli
Gzip is the long-standing standard, supported everywhere. Brotli is newer, developed for the web, and typically compresses a bit better, especially for text. Modern servers offer both and pick the best one the browser supports. For static assets, you can even pre-compress files at build time so the server just sends the ready-made compressed version.
How negotiation works
The browser advertises what it supports with an Accept-Encoding header, listing gzip, br and so on. The server compresses using one of those and signals its choice with a Content-Encoding header. The browser decompresses transparently, so the page works exactly as if it were uncompressed — just smaller and faster.
What to compress
- Compress text: HTML, CSS, JavaScript, JSON, SVG, XML.
- Do not re-compress already-compressed formats: JPEG, PNG, WebP, MP4, fonts in WOFF2.
- Skip compression for very small responses, where the overhead is not worth it.
The takeaway
If your server is not compressing text responses, enabling it is among the highest-value, lowest-effort performance changes available. Most servers and CDNs make it a one-line configuration.