Brotli and Gzip Compression: Turn It On and Verify It

Text files compress very well. HTML, CSS, JavaScript, JSON and SVG are full of repeated patterns, and a compression algorithm can shrink them before they cross the network. The browser then expands them again on arrival. If your server does not compress these files, every visitor downloads more bytes than they need to, which costs time on slow connections and data on mobile plans.

The two algorithms that matter for the web are gzip, which almost every server and browser supports, and Brotli, a newer one that usually compresses text more tightly. This guide is for site owners and developers who want to turn compression on, make sure it applies to the right files and nothing else, and prove with a real request that it works.

It will not make a slow page fast by itself. Compression reduces the size of text responses, and it does nothing for images, video or the time your server needs to build a page. The size reduction depends on the file, so treat any figure you read as an upper bound, not a result you will get.

Before you begin

You need to know where compression is configured: in your web server (Apache, Nginx or IIS), in a hosting control panel, in your application framework, or in a CDN. Many hosts and CDNs already compress by default, so start by checking before you change anything.

You need curl or a browser with Developer Tools to read response headers. Changing server configuration can break a site if a setting is wrong, so back up the file you will edit, change one thing at a time and test on a staging copy if you have one. Allow about 30 minutes.

How compression works on the web

MDN describes the negotiation in three parts:

The browser sends an Accept-Encoding request header listing the algorithms it understands, for example Accept-Encoding: gzip, deflate, br.
The server picks one, compresses the response body and labels it with a Content-Encoding header, for example Content-Encoding: br.
The server also sends a Vary header that includes Accept-Encoding, so a cache stores the compressed and uncompressed versions separately and serves each to the right client.

MDN says that, for this kind of end-to-end compression, only two algorithms are relevant: gzip, the most common, and br (Brotli). MDN's Content-Encoding reference also lists values such as deflate and zstd, but gzip and Brotli are the pair to plan around.

Search engine crawlers take part too. Google's crawler documentation says its crawlers support gzip, deflate and Brotli, and send the supported encodings in Accept-Encoding. So compressing helps crawlers fetch your pages efficiently as well, though it does not make them crawl more.

Step-by-step instructions

Step 1: Check what you have today

Run a request that offers both algorithms and prints the headers. The -H option adds a request header, and -I fetches headers only. Some servers answer a header-only request differently from a full one, so also test with a normal request and discard the body.

curl -s -o /dev/null -D - -H "Accept-Encoding: br, gzip" https://example.com/ | grep -iE "^(content-encoding|vary|content-type|content-length)"

If you see content-encoding: br or content-encoding: gzip, compression is already on for that URL. If the line is missing, the response was sent uncompressed. Repeat the test for a CSS file, a JavaScript file and an image, so you see the difference by file type.

In Chrome DevTools, open the Network panel, turn on "Big request rows" in settings, and look at the Size column. The top figure is the transferred (compressed) size and the bottom is the uncompressed size. Check the content-encoding response header in the Headers tab.

What success looks like: You know, per file type, whether compression is on and with which algorithm.

Step 2: Decide which files to compress

MDN's advice is to compress everything except files that are already compressed, such as images, audio and video. Compressing JPEG, PNG, GIF, WebP, MP4 or ZIP files a second time is often counterproductive, because the overhead can make the file larger. So target text types: HTML, CSS, JavaScript, JSON, XML (including your sitemaps), SVG, and plain text such as robots.txt. Web fonts in the WOFF2 format are already compressed with Brotli, so leave them out as well.

Lighthouse ignores very small files. Its text compression audit does not flag responses under 1.4 KiB, or responses where compressing with gzip would save less than 10 percent. That is a good guide to what is worth chasing.

What success looks like: You have a list of MIME types to compress, and images, video and fonts are not on it.

Step 3: Turn on compression in your server or host

The exact switch depends on your platform. MDN names the relevant pieces for the common servers:

Apache: the mod_deflate module (gzip).
Nginx: the ngx_http_gzip_module.
IIS: the httpCompression element in the configuration.

For Brotli you may need an additional module or a newer build of your server, so read your server's own documentation for its current options. On a CDN or managed host, look for a compression or "Brotli" setting in the dashboard. WordPress and Drupal sites generally rely on server or CDN compression, according to Lighthouse's stack-specific advice, rather than doing it inside the application.

An Nginx example of gzip for text types, as a starting point to adapt:

gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/css application/javascript application/json image/svg+xml application/xml;

HTML (text/html) is compressed by default when gzip is on in Nginx. Check your own server's documentation, because defaults and directive names vary by version.

What success looks like: After a reload of the configuration, the Step 1 test shows a content-encoding header.

Step 4: Pick sensible compression levels

Higher levels shrink files more but use more processing time. web.dev's CDN advice distinguishes two cases. For dynamic responses, compressed on every request, use a conservative level, such as Brotli level 4 (or gzip level 6 if Brotli is not available). For static files, which can be compressed once ahead of time or in the build step, use the highest levels, Brotli 11 or gzip 9. Many CDNs compress on the fly at a fast level and then recompress cacheable files at a higher level offline.

If your build tool can pre-compress static files to .br and .gz versions, your server can serve them without doing the work per request. That requires server support, so check how yours handles pre-compressed files.

What success looks like: Dynamic pages use a modest level and static files use a high one, or your CDN does this for you.

Step 5: Confirm the Vary header

A response that may be sent compressed or uncompressed depending on the request should include Vary: Accept-Encoding. Without it, a cache could store a compressed body and serve it to a client that cannot read it, or the reverse. MDN also advises sending the same Vary value on all responses for a URL. Check:

curl -sI -H "Accept-Encoding: gzip" https://example.com/style.css | grep -i vary

What success looks like: The Vary header contains Accept-Encoding on compressed responses.

Step 6: Test again with different clients

Request the same file with Accept-Encoding: br, then gzip, then with no Accept-Encoding header at all. The first should return Brotli if you enabled it, the second gzip, and the third an uncompressed body or identity. This proves your server picks per client and falls back safely.

If a CDN sits in front of your server, test the public URL, not the origin address, and check that the CDN does not strip the encoding or double-compress. A double-compressed response may fail to display correctly.

What success looks like: Each request returns the encoding you asked for, and the page still displays correctly in a browser.

Step 7: Run Lighthouse and compare

Rerun Lighthouse or PageSpeed Insights and compare the transfer size of your HTML, CSS and JavaScript with your baseline. As of Lighthouse 13, the text compression audit is part of the Document request latency insight. Crawvix has a check named "Text compression is on": it requests your home page offering gzip, deflate and Brotli, passes when the response uses a content encoding, fails when a page of 1,024 bytes or more is sent uncompressed, and treats smaller pages as too small to matter. It examines your home page only, so use Step 1 for other files.

What success looks like: Transfer sizes drop for text files and the Lighthouse compression opportunity no longer appears.

Final verification checklist

HTML, CSS, JavaScript, JSON and SVG responses return Content-Encoding: br or gzip.
Images, video and WOFF2 fonts are not compressed a second time.
Vary: Accept-Encoding is present on compressed responses.
A request with no Accept-Encoding header still returns a working, uncompressed page.
The public URL, behind any CDN, shows the same behavior as the origin.
Sitemaps and robots.txt still load correctly.
Lighthouse no longer flags text compression, or flags only very small files.
You saved before and after transfer sizes.

Common mistakes to avoid

Compressing images and video again. Already-compressed formats rarely shrink and can grow. Limit compression to text types.

Forgetting Vary: Accept-Encoding. Caches may then serve the wrong version to a client.

Using the highest level for every dynamic response. It can slow down page generation. Use a modest level for responses compressed per request.

Testing only the home page. Check CSS, JavaScript and other pages too, because rules are often per file type.

Testing the origin instead of the public URL. A CDN or proxy may change the behavior.

Compressing twice. If your application and your server both compress, you can get a double-encoded body. Turn it on in one layer.

Assuming Brotli is available everywhere. Not every server build includes it. Keep gzip as a fallback.

Frequently asked questions

Is Brotli better than gzip?

Brotli usually compresses text more tightly, and web.dev prefers it where available. Gzip remains a good fallback with the widest support. Many sites serve Brotli to clients that ask for it and gzip to the rest.

Does compression affect SEO?

Smaller responses can load faster, and Google's crawlers support gzip, deflate and Brotli. Compression does not directly change rankings, and this guide cannot say what it does for yours.

Should I compress images?

Not with gzip or Brotli. Image formats such as JPEG, PNG and WebP are already compressed. Improve them with the right format and size instead; see the WebP and AVIF guide.

How much smaller will my files get?

It depends on the file. MDN says a reduction of up to 70 percent is possible for some documents, which is a ceiling rather than an expectation. Measure your own files.

Why does Lighthouse still flag compression?

It may be flagging a file type your server skips, a third-party file you do not control, or a response that bypasses your configuration. Open the audit details to see the URL.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.