Brotli vs Gzip: Which Compression Should You Use?

Text compression is one of the simplest performance wins available: your server shrinks HTML, CSS and JavaScript before sending them, and the browser expands them back on arrival. The two dominant methods are Gzip, the long-standing default, and Brotli, the newer format that usually compresses text smaller. In practice you should offer both.

The short version

Enable Brotli as your primary text compression and keep Gzip as a fallback. Brotli typically produces smaller files for text, meaning faster downloads and better LCP. Both are supported by every modern browser. Compress text only — images and video are already compressed. Run a scan to see which your site sends.

How text compression works

Text files are full of repetition: the same tags, class names, and keywords appear over and over. Compression algorithms replace those repeated patterns with short references, so a 100 KB stylesheet might travel as 20 KB. The browser announces which formats it accepts with the Accept-Encoding request header, and the server replies with the format it used in Content-Encoding. Fewer bytes on the wire means the page arrives sooner, especially on mobile connections.

Where Brotli wins

Brotli generally achieves a better compression ratio than Gzip for text, particularly at higher quality levels, partly because it ships with a built-in dictionary of common web strings. For static assets you compress once and cache, you can use Brotli’s highest setting and store the result — the extra compression time is paid a single time, and every visitor downloads the smaller file.

For dynamic responses generated on each request, a mid-range quality level balances compression against CPU cost. The right trade-off depends on how often the content changes.

Where Gzip still matters

Gzip remains valuable as a fallback. It is universally supported, fast, and handles the rare client that does not advertise Brotli. A correct setup offers Brotli first and falls back to Gzip automatically based on the browser’s Accept-Encoding header — you are not choosing one or the other.

Quick comparison

AspectGzipBrotli
Text compression ratioGoodUsually better
Browser supportUniversalAll modern browsers
Best useFallback, dynamic contentPrimary, static assets
Highest quality costLow CPUHigher CPU (pre-compress once)

How to enable them

On Nginx, enable the gzip module and add the Brotli module, listing the text MIME types to compress:

gzip on;
gzip_types text/plain text/css application/javascript application/json;

brotli on;
brotli_types text/plain text/css application/javascript application/json;

On Apache, use mod_deflate for Gzip and mod_brotli for Brotli. Behind a CDN like Cloudflare, Brotli is often available with a single toggle at the edge — see our CDN guide. Whatever the platform, compress only text-based types.

Don’t double-compress. JPEG, PNG, WebP, AVIF, MP4 and most fonts are already compressed. Running them through Brotli or Gzip wastes CPU and can even make them slightly larger. Restrict compression to HTML, CSS, JavaScript, JSON, SVG and plain text.

Frequently asked questions

Do I have to pick just one?

No, and you shouldn’t. Configure both. The server serves Brotli to browsers that support it and Gzip to any that don’t, decided automatically from the request’s Accept-Encoding header.

Will compression slow down my server?

For static files, pre-compress once and cache the result, so there is no per-request cost. For dynamic content, a moderate quality level keeps CPU use low while still saving significant bytes.

Does compression help SEO?

Indirectly. Smaller responses load faster, improving Core Web Vitals like LCP, which contribute to Google’s page-experience ranking signals.

Related guides

Check your site against this guide

Run a free ScanOpsPro scan and see how your site handles the fundamentals.

Run a free scan