Website Compression with Gzip or Brotli; Which One Should You Enable?

High Website TTFB and Files Still Heavy

You've checked your site on PageSpeed Insights and it says "text compression is not enabled." Or you've measured TTFB and see 1.2 seconds, while the page content has almost no images. The first thing that comes to mind is enabling Gzip. But there's also the newer version, Brotli. Which one should you enable?

The short answer: Brotli, if your server allows it. But this answer comes with conditions and costs. In this article, I'll explain where and how to enable both, what numbers to expect from each, and where this can backfire.

The Real Difference Between Gzip and Brotli in Numbers, Not Slogans

Brotli is an algorithm Google released in 2015. Gzip is older and is still the web's default standard. The main difference lies in compression ratio and CPU usage.

On a real HTML file (like a news site's homepage with 85 KB of raw data), the numbers usually look like this:

• Gzip at level 6 (default): about 22 to 28 KB — a 67 to 74 percent reduction in size
• Brotli at level 5: about 18 to 21 KB — a 75 to 79 percent reduction in size
• Brotli at level 11 (maximum): about 16 to 18 KB, but compression time can take 10 to 20 times longer than Gzip

The 5 to 8 percent difference between Gzip and Brotli might seem small. For a CSS file that's 40 KB, that means saving 2 to 3 KB. But for a JSON file with 2 MB of data, the difference reaches 150 to 200 KB. On 50 GB of monthly traffic, that means several gigabytes less bandwidth.

Important note: Brotli has virtually no advantage on small files (under 1 KB). Sometimes it even produces output larger than Gzip. So if your site has lightweight pages, this optimization isn't at the top of the priority list.

Don't Underestimate the CPU Cost

Brotli at level 11 can consume 5 to 20 milliseconds of CPU time per file. On a shared server hosting 200 sites, this number adds up. This is where people make mistakes: they enable level 11 on all files and then wonder why the server CPU is at 90 percent.

The solution: perform compression once and cache the result. If you're using Nginx with the ngx_brotli module, set level 5 and enable the compression cache. If you've pre-compressed static files with the brotli -q 11 command, level 11 is fine because it's only done once.

Enabling on Nginx; Where You Have the Most Control

Nginx has Gzip by default, but Brotli needs to be installed as a separate module. On Debian and Ubuntu, the nginx-extras package includes ngx_brotli. On other distributions, you'll need to compile it from source.

For Gzip in the http or server block:

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

For Brotli, after installing the module:

brotli on;
brotli_comp_level 5;
brotli_min_length 1024;
brotli_types text/plain text/css application/json application/javascript application/xml image/svg+xml;

Note that you can also add brotli_static on; so Nginx serves pre-compressed files with the .br extension directly. This reduces CPU cost to zero.

A subtle point: if both modules are enabled, Nginx decides based on the browser's Accept-Encoding header. Modern browsers (Chrome 50+, Firefox 44+, Safari 11+) support Brotli. The rest fall back to Gzip. So enabling both is fine, as long as you set the order correctly.

Enabling on Apache and cPanel

Apache works with the mod_deflate module. In cPanel, this module is usually enabled, and you just need to write the rules in the .htaccess file:

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css application/json application/javascript application/xml image/svg+xml
DeflateCompressionLevel 6
</IfModule>

The problem is: Apache doesn't have Brotli by default. The mod_brotli module needs to be compiled separately and is usually not enabled on shared hosting. If you have shared Linux hosting, first check whether mod_brotli is in the list of loaded modules:

httpd -M | grep brotli

If the output is empty, you only have Gzip. That's not bad. Gzip at level 6 is sufficient for 95 percent of websites, and its difference from Brotli isn't noticeable to the end user unless you have large JSON or JavaScript files.

In cPanel, if the Brotli module is enabled, you can write in the .htaccess file:

<IfModule mod_brotli.c>
AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css application/json application/javascript image/svg+xml
BrotliCompressionQuality 5
</IfModule>

But if you're on shared hosting and this module isn't enabled, requesting installation from the support team usually yields no results. In this case, the best approach is to pre-compress static files and serve them with the Content-Encoding: br header. Tools like brotli on Linux do this:

brotli -q 11 -f style.css -o style.css.br

Then add rewrite rules in .htaccess so that if a .br file exists and the browser supports it, that file is served.

Which One Should You Choose? A Practical Decision

If you have full control over your server (dedicated server or VPS), enable Brotli at level 5 and keep Gzip as a fallback. This combination offers the best compression-to-CPU-cost ratio.

If you're on shared hosting and only Gzip is available, enable it at level 6 and move on to other optimizations. Compression is just one factor in speed. WebP images, browser caching, and removing unused JavaScript usually have a bigger impact.

The condition for choosing Gzip over Brotli: if your server has weak CPU (e.g., 1 shared core) and receives high traffic, Gzip is the safer choice. Real-time compression with Brotli on weak hardware can increase TTFB by 100 to 200 milliseconds. That's exactly what you were trying to fix.

Another note: if your site is behind a CDN, the CDN usually handles compression, and your origin server settings become ineffective. On Cloudflare, enable the Brotli option in the Speed section and let the CDN manage it. In this case, your Nginx or Apache settings only apply to requests that go directly to your server.

Here's Where They Make Mistakes: Re-compressing Already Compressed Files

The most common mistake I've seen: someone includes PNG or JPEG files in the gzip_types or brotli_types list. This not only doesn't reduce size but also wastes CPU and in some cases makes the file larger. PNG and JPEG images are already compressed, and re-compressing them with Gzip or Brotli typically reduces size by 0 to 2 percent while consuming 5 to 15 milliseconds of CPU.

The sign of this mistake: check your server logs. If you see .png requests being served with the Content-Encoding: gzip header, you've made this mistake. Compress text files: HTML, CSS, JavaScript, JSON, XML, SVG, woff2 fonts (although they're already compressed). Not images, not videos, not PDFs.

Second mistake: enabling compression on small responses. gzip_min_length 0 or omitting this line means even 200-byte responses get compressed. The CPU cost for these responses outweighs the bandwidth savings. Set a minimum of 1024 bytes.

Measurement; Before and After the Change

Before making any changes, measure the current state. Two simple tools:

1. Command line: curl -H "Accept-Encoding: br" -o /dev/null -s -w "size_download: %{size_download}\ntime_total: %{time_total}\n" https://example.com/
2. Browser: In DevTools, Network tab, look at the Size column. The first number is the transferred size and the second is the raw size. If they're equal, compression isn't working.

You can also use free webmaster tools to check response headers. The Content-Encoding: br or Content-Encoding: gzip header should be present in the response. If neither is there, your settings haven't been applied.

After the change, measure again. If TTFB increases by more than 50 milliseconds and the size only decreases by 5 percent, lower the compression level or enable the compression cache.

The Relationship Between Compression and Other Optimizations

Text compression is just one layer of optimization. If your site is slow, first figure out where the problem is. Compression doesn't affect TTFB. High TTFB usually comes from slow server response, heavy database queries, or DNS. If your TTFB is above 500 milliseconds, compression won't improve the situation.

For systematic troubleshooting, read the complete guide to diagnosing a slow website. It outlines the order of operations: first DNS, then TTFB, then response size, then browser rendering.

If your site is on shared hosting and you're facing resource limits, maybe it's time to migrate to a dedicated server. High-level Brotli compression on a server that only hosts your site can be done without worrying about other people's CPU usage.

Frequently Asked Questions

Does Brotli make a noticeable difference in website speed compared to Gzip?

For the end user, the difference is usually between 5 and 15 percent in loading time, depending on the volume of text files on the site. On high-speed connections, this difference isn't noticeable. On 3G connections or high-latency internet, the difference is more apparent. If your site has large JSON or JavaScript files, Brotli is worth it.

How do I know if compression is enabled on my site?

Use the command curl -I -H "Accept-Encoding: gzip, br" https://example.com/ to see the response headers. If Content-Encoding: br or Content-Encoding: gzip appears in the output, compression is enabled. Online tools like GTmetrix also show this.

Does enabling both Gzip and Brotli simultaneously cause any problems?

No. The server chooses the best option based on the browser's Accept-Encoding header. Modern browsers prefer Brotli, and older browsers fall back to Gzip. Just make sure both modules are properly installed and the settings don't conflict with each other.

Which files should I not enable compression on?

On images (JPEG, PNG, GIF), videos, audio files, and PDFs. These files are already compressed, and re-compressing them only wastes CPU. Limit compression to text files: HTML, CSS, JavaScript, JSON, XML, and SVG.