Compression, in website performance, means the server shrinks text files such as HTML, CSS, JavaScript, JSON and SVG before sending them, and the browser unpacks them on arrival. Gzip and Brotli are the two formats almost every site uses.
How compression works
When a browser requests a page, it sends a header called Accept-Encoding listing the formats it understands, for example “gzip, deflate, br”. The server picks one, compresses the file and replies with a Content-Encoding header saying which it used. The browser decompresses the file before reading it. The whole exchange is invisible to the visitor.
Text compresses well because code is full of repetition: the same tag names, class names and function calls appear over and over. A large stylesheet or JavaScript bundle can often shrink to a small fraction of its original size.
- Gzip has been around since the 1990s and is supported by every browser and server. It is the safe baseline.
- Brotli was developed by Google and usually produces smaller files than Gzip for web text, partly because it ships with a built-in dictionary of common web strings. Every current major browser supports it over HTTPS.
- Zstandard is a newer option. At the time of writing (October 2026) Chrome and Firefox accept it, but Gzip and Brotli remain the formats to get right first.
Compression can happen on the fly for each request, or files can be compressed once in advance and stored. Static assets such as theme stylesheets are good candidates for pre-compression at a high setting, since the work is done once. A content delivery network will often handle Brotli for you at its edge servers.
Why it matters
Fewer bytes means faster downloads, and the difference is largest where connections are weakest: a visitor on a patchy 4G signal on a train out of Waterloo, or in a rural area with slow broadband. The HTML document and the CSS that blocks rendering both have to arrive before anything is painted, so compressing them helps the first paint and the Largest Contentful Paint directly.
It is also one of the cheapest performance wins available. On most hosting it is a configuration setting rather than a development project, which is why I check it early in any technical review. A site that sends uncompressed HTML and scripts is wasting bandwidth on every visit, for every visitor, including Googlebot.
Common mistakes
- Assuming the host has switched it on. Many do, some do not, and some compress HTML but not CSS or JavaScript. Check the response headers rather than the host’s sales page.
- Compressing images and video again. JPEG, PNG, WebP, AVIF and MP4 are already compressed. Running Gzip over them uses server time for no saving.
- Double compression. A plugin and the server both compressing the same file can produce garbled output or errors. Do it in one place.
- Confusing compression with minification. Minification removes unnecessary characters from the code itself; compression packs what is left for transfer. You want both.
How to act on it
Open your site in Chrome, open developer tools, go to the Network tab and reload. Click the HTML document and a stylesheet and look for “content-encoding: br” or “content-encoding: gzip” in the response headers. PageSpeed Insights will also flag text resources that are sent uncompressed, though checking the headers yourself is the surer test.
If compression is missing, the fix depends on your setup: an Apache or nginx setting, a toggle in your hosting control panel, a caching plugin on WordPress, or a CDN option. On managed platforms such as Shopify, Squarespace and Wix it is handled for you. If the headers look right but pages are still slow, the cause lies elsewhere, and finding it is part of my technical SEO work.