Compression is the easiest page speed win available, and it is off more often than people think. How to verify it is actually working, why Brotli changed the picture, and the setting that silently skips your largest files.

Compression is the rare page speed improvement that costs nothing and breaks nothing. Turning it on typically cuts the size of your HTML, CSS and JavaScript by around 70 percent, and it takes a few lines of server configuration.

Which makes it strange how often it is switched off. Not because anyone decided against it, but because the assumption is that hosting handles it automatically. Sometimes hosting does. Often it handles it for some file types and quietly skips others, and nobody checks because the site loads fine on a fast connection.

What Compression Actually Does

When a browser requests a page, it announces what it can handle in a request header:

Accept-Encoding: gzip, deflate, br

If the server supports one of those, it compresses the response before sending and says so in a response header:

Content-Encoding: gzip

The browser decompresses it before rendering. The user sees nothing different — only that the page arrived faster.

Text-based files compress dramatically because they are full of repetition: the same tag names, the same property names, the same whitespace patterns over and over. Images and video do not, because they are already compressed in their own formats. Running gzip over a JPEG wastes CPU and saves nothing.

• Compress: HTML, CSS, JavaScript, JSON, XML, SVG, plain text
• Do not compress: JPEG, PNG, WebP, MP4, PDF, ZIP, fonts in WOFF2

Gzip or Brotli?

Brotli is newer, achieves roughly 15 to 20 percent better compression on text, and is supported by every modern browser. The br in that Accept-Encoding header above is Brotli.

The practical answer is not to choose. Serve Brotli where the browser supports it and fall back to gzip where it does not. Both are trivial to enable together, and browsers negotiate automatically.

One detail worth knowing: Brotli has compression levels from 0 to 11, and the higher levels are slow enough that they are meant for files compressed once and cached, not for pages generated on every request. For dynamic HTML, a level around 4 or 5 gives most of the benefit at a fraction of the cost. Static assets can use the highest level, since the work happens once.

How to Check Whether It Is Actually On

The important word is actually. Enabling compression in a control panel and having it apply to your responses are two different things, and plenty of setups have the first without the second.

1. Test from outside your own server

A gzip compression test fetches your page the way a browser would and reports whether the response came back compressed, along with the size difference. This is the fastest check, and it tests the real path, including any proxy or CDN in front of your server.

2. Read the response headers directly

The HTTP headers parser shows the full response, where you are looking for Content-Encoding: gzip or Content-Encoding: br. If that header is absent, nothing is being compressed regardless of what your configuration says.

3. Check from a terminal

curl -I -H "Accept-Encoding: gzip, br" https://example.com

The -H flag matters. Without it, curl does not announce that it accepts compression, so the server correctly sends an uncompressed response and you conclude compression is broken when it is not. This trips people up constantly.

4. Test each file type separately

This is the step almost everyone skips, and it is where the real problems hide.

Compression is configured per MIME type. A default configuration usually covers text/html and often text/css, but frequently omits application/javascript, application/json, and image/svg+xml. Since JavaScript is usually the largest thing on the page, missing it means missing most of the benefit.

Test your HTML, then your main stylesheet, then your main JavaScript bundle, as separate URLs.

The pattern I run into most is a site where compression is genuinely enabled and genuinely working — on the HTML only. Someone tests the homepage, sees gzip in the headers, and marks it done. Meanwhile the JavaScript bundle, which is four times the size of the document, is going out raw because its MIME type was never added to the list. Checking one URL and assuming the rest tells you almost nothing.

5. Look at what your CDN is doing

If Cloudflare or another CDN sits in front of your site, it may be compressing on its own, or it may be passing through whatever the origin sends. These can disagree. A response can arrive compressed to visitors while your origin server sends nothing, or the reverse.

Enabling It

On Apache, compression is handled by mod_deflate in .htaccess:

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

On Nginx, it goes in the server configuration:

gzip on;
gzip_types text/plain text/css application/javascript application/json image/svg+xml;
gzip_min_length 256;

On shared hosting, there is usually a toggle in the control panel — on Hostinger and most cPanel hosts it is under the performance or optimisation section. Turn it on, then verify from outside rather than trusting the toggle.

Note the gzip_min_length setting. Compressing very small files can produce output larger than the input, because of the compression header overhead. A threshold of a few hundred bytes avoids that.

What This Is Worth in Search

Compression does not have its own ranking signal. Its effect runs through page speed, which does.

Core Web Vitals measure loading performance, and Largest Contentful Paint is directly affected by how long it takes to transfer the resources needed to render. Cutting your CSS and JavaScript payload by 70 percent moves that number, particularly on slower connections where transfer time dominates.

Compression is worth checking first when a site feels slow, purely because of the effort-to-benefit ratio. Most page speed work means auditing scripts, deferring things, arguing about which third-party tags can go. This is a configuration change that takes minutes and needs no decisions from anyone. It is also the one thing that is often already half-done, which is why testing beats assuming.

The effect is largest exactly where it matters most: mobile users on constrained connections, which for most sites is the majority of traffic.

Frequently Asked Questions

Should I use gzip or Brotli?

Both. Enable Brotli for browsers that support it and keep gzip as the fallback. Browsers negotiate automatically through the Accept-Encoding header, so there is no downside to offering both.

Does compression slow down my server?

Slightly, in CPU terms, but the trade is heavily in your favour. Transfer time saved far exceeds compression time added for text files. Use moderate compression levels for dynamic content and high levels for static assets that get cached.

Why does my test say compression is off when I enabled it?

Most often, the test did not send an Accept-Encoding header, so the server correctly returned an uncompressed response. Otherwise, the MIME type of that particular file is not in your compression list, or a proxy is stripping the header.

Should I compress images?

No. JPEG, PNG, and WebP are already compressed. Running gzip over them burns CPU for no size reduction, and can occasionally produce a slightly larger file. Optimise images with image tools instead.

My host says compression is enabled but the headers disagree. What now?

Trust the headers. Test each file type individually, then check whether a CDN or proxy sits between the origin and the visitor. The header on the response the browser actually receives is the only thing that counts.

The Short Version

Compression is close to free and usually half-configured. Test your HTML, your CSS, and your JavaScript as separate URLs rather than testing the homepage and assuming — the largest file on your page is the one most likely to be going out uncompressed.

Written by Baleeghuddin Shaikh, SEO consultant with 8 years of experience in technical SEO and site diagnostics.