Text compression is one of the few performance levers that's almost entirely up to your host rather than your theme or plugins — and Brotli vs. Gzip is the specific choice that determines how much smaller your HTML, CSS, and JS get before they're sent over the wire. Here's what actually differs between them and how much it moves the needle.
What each one actually does
Both Brotli and Gzip are lossless compression algorithms applied to text-based assets (HTML, CSS, JavaScript, JSON, SVG) before the server sends them to the browser, which then decompresses them automatically — this is transparent to visitors and doesn't require anything on the client side beyond standard browser support, which both formats have had for years. Gzip has been the web's default for over two decades. Brotli, developed by Google and standardized more recently, generally compresses the same content smaller than Gzip at an equivalent compression level, particularly for text-heavy assets, because it uses a larger, web-content-tuned static dictionary and a more efficient entropy coding scheme.
How much smaller, in practice
Across typical WordPress front-end assets — theme CSS, bundled JS, and rendered HTML — Brotli at a comparable compression level commonly produces files somewhere in the range of 15–25% smaller than Gzip on the same content, though the exact gap varies by asset type: highly repetitive, verbose markup (typical WordPress-generated HTML with a lot of class names and boilerplate) tends to see a larger relative improvement than already-minified, dense JavaScript. On a real page, that translates to a modest but real reduction in transfer size and time-to-first-byte-adjacent metrics, most noticeable on slower connections where every kilobyte transferred matters more.
The trade-off: compression time vs. file size
Brotli's smaller output at high compression levels costs meaningfully more CPU time to produce than Gzip at an equivalent level — which is why most production setups don't compress Brotli assets on the fly per-request. The standard approach is pre-compressing static assets (CSS/JS bundles) at build or deploy time and serving the pre-compressed `.br` file directly, while using dynamic (on-the-fly) compression only for content that can't be pre-generated, like the final rendered HTML of a page. Hosts and CDNs that support Brotli properly handle this distinction for you; a host that only offers on-the-fly Brotli at max compression level for every request can actually add latency rather than removing it, since the CPU cost of compressing outweighs the transfer-size savings on fast connections.
Where support actually comes from
| Layer | What determines support |
|---|---|
| Web server (Nginx, Apache, LiteSpeed) | Needs the Brotli module compiled in or enabled; Gzip is virtually always available by default, Brotli isn't guaranteed on every stack |
| CDN (Cloudflare, etc.) | Most major CDNs support Brotli at the edge regardless of origin server support, which is often the easiest way to get it without touching server config |
| Managed WordPress hosting | Varies by provider — some enable Brotli by default at the server/CDN layer, others still default to Gzip-only unless you push for it via support |
| Basic shared hosting | Least likely to offer Brotli configuration control; often stuck with whatever the shared server-wide default is |
How to check what you're actually getting
Open browser dev tools, go to the Network tab, reload the page, and check the `Content-Encoding` response header on the main document and key assets — it will read `br` for Brotli or `gzip` for Gzip (or `identity`/absent if neither is applied, which is worth catching since uncompressed text assets are a much bigger loss than the Brotli-vs-Gzip gap). If a host claims Brotli support but every asset still shows `gzip`, that's a sign it needs to be explicitly enabled rather than assumed on.
Is it worth switching hosts over?
On its own, no — the real-world difference between well-configured Gzip and well-configured Brotli is a meaningful but secondary optimization, not a page-speed transformation. It's worth actively enabling if your current host supports it and it's simply off by default (a free win), and worth weighing as one factor among several if you're already comparing hosts for other reasons. It is not, by itself, a reason to migrate a site that's otherwise well optimized.
FAQ
Do images benefit from Brotli or Gzip? No — JPEG, PNG, and WebP are already compressed formats; applying text compression on top does essentially nothing and most servers correctly skip it for image MIME types.
Will enabling Brotli break anything for old browsers? Practically no — Brotli has had broad browser support for years, and servers correctly fall back to Gzip or uncompressed for any client that doesn't advertise Brotli support in its request headers.
Does a CDN's Brotli support replace the need for origin-server compression? Mostly yes for cached content served from the edge, but uncached or dynamic responses that pass through to origin still depend on the origin server's own compression configuration.
Verdict
Brotli reliably beats Gzip on text-asset size by a meaningful single-digit-to-low-double-digit percentage, but the real-world impact depends entirely on whether it's implemented correctly (pre-compressed static assets, sane compression level for dynamic content) rather than just “turned on.” Check your `Content-Encoding` headers before assuming either way, push for Brotli if your host supports it and hasn't enabled it, and treat it as a secondary optimization rather than a primary hosting decision.
