Gzip or Brotli? Why your site must compress its pages

An uncompressed page can weigh 5 times more than necessary. Test #01 checks it instantly — and the fix takes under 5 minutes.

A typical WordPress page generates 50–200 KB of HTML. Add the CSS, the JavaScript, and the web fonts — and you easily reach 1 MB of text-based resources. Multiply that by every visitor, every page load.

HTTP compression solves this: the server compresses the response before sending it, the browser decompresses it on arrival. The transfer shrinks by 60–80%. The visitor downloads less, the page loads faster, and Google notices.

The surprising part? About 15% of WordPress sites still don't have compression enabled. It's not a complex optimization — it's a server setting. And test #01 in Orilyt detects it in under 2 seconds.

How HTTP compression works

When your browser sends a request, it includes an Accept-Encoding header listing the compression formats it supports (typically gzip and br for Brotli). The server picks one, compresses the response, and sends it back with a Content-Encoding header.

1. Gzip — the universal standard since the 2000s. Supported by every browser and server. Reduces text by 60–70%. Fast compression and decompression
2. Brotli (br) — developed by Google, available since 2016. Compresses 15–25% better than Gzip on average. Supported by all modern browsers. Slightly slower to compress but faster to decompress
3. No compression — the server sends raw text. The browser receives 3–5× more data than necessary. Load times increase proportionally

Compression applies to all text-based resources: HTML, CSS, JavaScript, JSON, XML, SVG. Images (JPEG, PNG, WebP) are already compressed by their format and are not affected.

In practice, Brotli is the better choice when available. But Gzip is perfectly fine — the important thing is that compression is enabled at all.

How Orilyt scores compression

Test #01 is binary. Orilyt inspects the Content-Encoding header of the server's response:

1. Header contains "br" or "gzip" → Score 100 — Compressed. The server is doing its job
2. Header is missing or empty → Score 25 — Not compressed. Every page load transfers unnecessary data

Orilyt also detects the compression source. If a CDN like Cloudflare or QUIC.cloud is in front of the site, it often handles compression at the edge — even if the origin server doesn't. The test distinguishes between CDN compression and origin compression.

Why compression is sometimes missing

If compression is so simple, why is it missing on 15% of sites? Common reasons:

1. Default server configuration — some hosting providers ship with compression disabled. The site owner never checks
2. Misconfigured .htaccess — a plugin or manual edit removed the mod_deflate/mod_brotli rules. Or an .htaccess reset wiped them out
3. Nginx without gzip on — Nginx has compression disabled by default. You need to explicitly add gzip on; to the config
4. Reverse proxy conflict — a load balancer or WAF strips the Content-Encoding header. The origin compresses, but the visitor receives raw text

The good news: in 90% of cases, the fix takes under 5 minutes. It's either a checkbox in the hosting panel, a line in .htaccess, or a plugin setting.

Compression as a selling point

For freelancers and agencies, a missing compression finding is gold. It's easy to explain, dramatic in impact, and trivial to fix:

In the Orilyt report, test #01 generates a structured FIA recommendation:

1. Fact: "No HTTP compression detected — the page is served at full weight (187 KB instead of ~45 KB)"
2. Impact: "Every visitor downloads 4× more data than necessary. On mobile connections, this adds 1–3 seconds to load time"
3. Action: "Enable Gzip or Brotli compression in the server configuration — estimated improvement: 60–80% weight reduction"

A score of 25/100 on the very first test of the audit immediately signals a neglected site. It's the kind of finding that makes a client say "we need help."

The 5-minute fix that changes everything

Compression is the lowest-hanging fruit in web performance. No code changes, no redesign, no complex caching strategy — just a server setting that reduces every page transfer by 60–80%.

Test #01 in Orilyt detects it instantly. The binary scoring (100 or 25) makes the result crystal clear — there's no ambiguity.

If you're building audit-based proposals for clients, this is the test that demonstrates immediate, tangible value. A 5-minute fix with a measurable before/after. That's how you start a conversation.