Every page on your website is built from text files: the HTML that holds the words and structure, the CSS that styles it and the JavaScript that makes things move. Before those files travel to a visitor, the server can squeeze them, much like zipping a folder before you email it, and the browser unpacks them on arrival. Nothing changes on screen. It's usually a server or hosting setting rather than a redesign, and it's worth five minutes to confirm it's switched on.
What gzip and Brotli actually do
Text is full of repetition: the same tags, class names and words appear again and again. Compression replaces those repeats with shorter references, without losing a single character. MDN's compression guide says that for some documents a size reduction of up to 70% is possible, and that today only two methods are really relevant for the web: gzip, the most common, and Brotli (written br), the newer one. Brotli is defined in RFC 7932, published in 2016.
The browser and server agree on a method each time. The browser sends an Accept-Encoding header listing the methods it understands; the server picks one and labels its response with a Content-Encoding header. Google's Lighthouse guidance recommends Brotli where the browser supports it, because it typically produces smaller files, with gzip as the widely supported fallback.
Check whether your site compresses
You don't need to be a developer to look. In Chrome:
- Open your page, open DevTools (F12, or Cmd+Option+I on a Mac) and choose the Network panel. Tick “Disable cache” and reload, so you see what a first-time visitor downloads.
- Click the first request (your page itself). In the Headers tab, look under Response Headers for
content-encoding. A value ofbrorgzipmeans the file was compressed. If the line is missing, it wasn't. - Repeat for a couple of your own CSS and JavaScript files. Use the Doc, CSS and JS filter buttons at the top of the panel to find them.
- At the bottom of the panel, Chrome shows how much was “transferred” and the uncompressed size of the “resources”. A large gap between the two on a text-heavy page is a sign compression is doing its job.
PageSpeed Insights also checks this. Older reports showed an “Enable text compression” audit, which Lighthouse used to flag text files sent without compression. Google has since folded that audit into the Document request latency insight, which reports when the response for the page itself was uncompressed. That insight looks at the main HTML document, so it's still worth checking your CSS and JavaScript files by hand as above.
Why images and video don't benefit
If compression is so useful, why not apply it to everything? Because photos and video are already compressed by their own formats. MDN notes that JPEG images and web video formats are lossy, and recommends compression for all files except those already compressed, such as images, audio and video. Its Content-Encoding reference adds that compressing them again can even increase the file size.
So a missing content-encoding header on a JPEG is normal and nothing to fix. Making images lighter is a different job: the right size and a modern format. Our article on image weight covers that.
What a carbon test counts
GreenTracer measures one first, uncached load of your page with Google PageSpeed Insights, on mobile and desktop, and uses the heavier of the two. The figure it uses is the data sent over the network, which means the compressed size of each file, not the size once the browser has unpacked it.
That is why compression shows up directly in your result. As an illustration, if your HTML, CSS and JavaScript together were sent uncompressed at 1.5 MB and compression brought them down to 0.5 MB, that 1 MB difference would be worth about 0.148 g CO₂e per page view under the Sustainable Web Design Model v4 (about 0.121 g on a host listed as green). The real difference on your site depends on your files; the Network panel comparison above is the way to find out. If your site already compresses, which is common, the gain here is zero, and your time is better spent elsewhere.
Turning it on
- Check your host or CDN settings first. Some offer compression as a switch in their control panel. If you can't find it, ask their support whether gzip or Brotli is enabled for HTML, CSS and JavaScript.
- On your own server, it's a web server setting. MDN points to the modules for Apache, Nginx and IIS.
- On WordPress, Lighthouse's guidance is to enable compression in the web server configuration rather than in the theme.
- Then check the headers again using the steps above, and check your page again after the change. Saved reports keep the earlier result as history, so you can compare the two.
Compression is one of several small server-side settings that add up. For the wider list, see our practical tips for a lighter website, and our guide to what each grade means.
Sources
- MDN: Compression in HTTP
- MDN: Content-Encoding header
- RFC 7932: Brotli Compressed Data Format
- Lighthouse: enable text compression
- Chrome for Developers: moving Lighthouse to insights
- Chrome for Developers: Document request latency insight
- Chrome DevTools: Network features reference
- Sustainable Web Design: estimating digital emissions (SWDM v4)
