Skip to content
Website Speed

Gzip vs Brotli Compression: Check and Enable It

Compression shrinks HTML, CSS and JavaScript on the way to the browser. Here is how gzip and Brotli differ, how to check your site, and where to switch it on.

A laptop showing website analytics charts
10 sections · 8 min read
In this article · 10 sections

The speed report lists it in plain words, “Enable text compression”, along with a handful of your stylesheets and scripts and an estimate of how much smaller they could be. You looked in your caching plugin and found a GZIP checkbox that is already ticked. Then someone mentioned Brotli, and now there are two things you may or may not have.

This is one of the more satisfying items on a speed report, because it is usually quick to settle and nothing on the page changes visually. Gzip vs Brotli compression comes down to a handful of practical points: what compression does, how to check whether your site already sends it, which method to prefer, and which few files to leave alone.

What text compression does

Before sending a text file, the server squeezes it, a bit like zipping a folder before emailing it. The browser receives the smaller version and unpacks it straight away. Visitors never see any of this; they simply receive fewer bytes.

Text files compress very well because they are full of repetition. A stylesheet repeats the same property names hundreds of times. HTML repeats the same tags and class names. JavaScript repeats function and variable names. Compression finds those repeats and stores them once.

The files it applies to:

  • HTML pages
  • CSS stylesheets
  • JavaScript files
  • SVG images, which are text underneath
  • JSON, XML and other data responses, including WordPress REST API replies
  • Plain text, such as robots.txt or sitemaps

On a typical page the CSS and JavaScript are where most of the saving sits, since those files are often large and requested on every page.

How the browser and server agree on a method

Every request from a modern browser includes a header listing the compression methods it understands, something like Accept-Encoding: gzip, deflate, br. The br there is Brotli. The server picks one it supports and labels the reply, for example Content-Encoding: br or Content-Encoding: gzip.

If the server supports neither, or compression is switched off, the reply has no Content-Encoding header and the file travels at full size. That missing header is what the speed report spotted.

Gzip vs Brotli compression: the real differences

Both do the same job. The differences are in how much they squeeze and where they work.

Gzip Brotli
Age and support Very old, supported by every browser and server Newer, supported by current major browsers
Typical result on text Good Usually somewhat smaller files than gzip
Works over plain HTTP Yes Browsers only offer it over HTTPS
Speed of compressing Fast Fast at moderate levels, slow at its highest levels
Where it is set up Almost every server, often on by default Needs server support or a CDN

That compression-speed row is worth understanding. Brotli has a range of levels. The highest ones squeeze hardest but take a long time, which is fine for a file compressed once and stored, and poor for a page compressed fresh for every visitor. Servers that compress on the fly therefore tend to use a middle level. Some setups pre-compress static CSS and JavaScript at a high level once and keep that copy ready.

In practice the advice is simple. Offer Brotli where your server or CDN supports it, keep gzip as the fallback, and let the browser choose. You do not have to pick one for everyone; the Accept-Encoding exchange handles it per visitor.

You may also see a newer method, Zstandard, mentioned in CDN dashboards. It works the same way through the same headers, and the same fallback rule applies.

How to check whether your site is compressed

In the browser

  1. Open a page on your site, open developer tools and go to the Network tab.
  2. Reload, then click your HTML document, the first row.
  3. Under Response Headers, look for content-encoding. You want br or gzip.
  4. Repeat for one of your own stylesheets and one of your own scripts. A server can compress HTML but miss other file types if it was set up partly.

The Size column helps too. With the larger request rows option turned on in the Network panel settings, Chrome shows two figures for each file: what travelled over the network and the size after unpacking. For a compressed CSS file the first is much smaller than the second.

From a terminal

If you have one handy, curl -sI -H "Accept-Encoding: br, gzip" https://yourdomain.com/ prints the response headers, including content-encoding if compression is on.

Only judge your own files. Third-party scripts come from other companies’ servers, and their compression is their business. If the report lists a third-party file as uncompressed, there is usually nothing you can do except question whether you need that script.

How to enable text compression

Where you switch it on depends on who is answering visitors’ requests.

  • Shared hosting. Most hosts compress text by default. If your check shows none, ask the host before adding anything yourself. Some panels have a simple setting for it, and on LiteSpeed servers compression is normally handled by the server.
  • Caching plugins on Apache. Several caching plugins can add compression rules to your .htaccess file. This works only if the server’s compression module is available. It is a reasonable fallback, not a replacement for server support.
  • Your own VPS. Gzip is a standard part of Apache and Nginx. Brotli needs its module installed and enabled. Follow the web server’s own documentation and test after each change.
  • Behind a CDN. When a CDN sits in front of the site, visitors receive files from the CDN, which usually compresses text itself, often with Brotli. In that case what your origin server does matters less for visitors, though it still affects the CDN’s fetches.

Change one layer at a time, then run the browser check again on HTML, CSS and JavaScript.

What not to compress

Images, video and most font files are already compressed by their own formats. JPEG, PNG, WebP, AVIF, MP4 and WOFF2 files gain little or nothing from gzip or Brotli, and asking the server to try wastes processor time on every request. Good default server settings already skip them.

Making those files smaller is a separate job: the right format, the right dimensions and sensible quality settings. Our guide to optimising images for the web covers that side.

The exception is SVG. It is text, it compresses well, and it is sometimes missed in compression settings that were written with only CSS and JavaScript in mind.

Problems you might run into

A garbled page or a decoding error

If a page suddenly shows strange characters, or Chrome reports a content decoding error, the response may have been compressed twice: once by a plugin and again by the server or a proxy. Turn off the plugin’s compression option and test again.

Compression on HTML but not on files

Some rules only list certain content types. If stylesheets are compressed and scripts are not, the configuration needs the missing type added.

The warning stays after you fixed it

A page cache or CDN may still be serving copies stored before the change. Purge the caches and test again.

Measuring what it changed

Before switching anything on, note two figures from the Network tab for your homepage: the total transferred at the bottom of the panel, and the transferred size of your largest stylesheet and script. After the change, purge caches, reload with cache disabled and note them again. The difference is the real saving on your site, which is more useful than the estimate in the speed report.

Expect the visible effect to depend on the visitor. On fast broadband a few dozen kilobytes saved can be hard to feel. On a slow mobile connection, where every kilobyte takes time, the same saving brings the page’s styles and scripts in noticeably sooner.

Compression is not minification

The two get mixed up because both make text files smaller. Minification rewrites the file itself, stripping spaces, comments and long names, and it carries some risk of breaking scripts. Compression leaves the file as it is and only packs it for the journey. They work together, and compression usually saves more with no risk to the code. Our post on what minifying CSS and JavaScript removes covers the other half.

Compression is one of the server settings looked at in our section guide on how the hosting affects page speed, and it is a small, settled item in the wider full guide to website speed.

Frequently asked questions

Is Brotli worth asking my host for if gzip is already on?

It is a modest gain rather than a big one. Brotli usually produces somewhat smaller text files, which helps visitors on slow or metered connections most. If your host or CDN offers it with a simple setting, switch it on and keep gzip as the fallback. If it needs a server rebuild, it can wait behind bigger fixes.

Does compression slow my server down?

It uses a little processor time for each response, which is why servers compress on the fly at moderate levels. For text files the time saved on the network is normally far greater than the time spent compressing. Problems mainly appear with very high Brotli levels applied to every request, or when servers try to compress images and video.

Should my caching plugin handle compression or the server?

The server, where possible. It compresses every response consistently, including files the plugin never sees. A plugin’s compression option is useful mainly on Apache hosting where the server supports it but nobody has enabled it. Having both active at once can cause double compression, so pick one.

Does text compression help Core Web Vitals?

Indirectly. Smaller stylesheets and scripts arrive sooner, which can bring the main content forward and improve LCP, especially on slow connections. Compression does nothing for layout shift, and it has little effect on how quickly the page responds to taps, since the browser still has to run the same JavaScript once it arrives.

The header check on one page, one stylesheet and one script takes a couple of minutes, so it is worth doing today. If compression turns out to be only one of several problems, our website speed optimisation service starts with a full audit and a prioritised fix list, and you approve each change before we make it.

Next in this series: Shared Hosting Resource Limits: What Each One Does

Is Your Website Working Properly?

Get a free website health check from WebMaintor. We'll review your website's speed, security, forms, and technical health — and tell you exactly what needs attention.

No obligation. No automated reports. A real review by our team.