GZIP vs. Brotli Compression: Which is Better for WordPress?

The short answer: Brotli is better for WordPress in most cases, shrinking HTML, CSS and JavaScript roughly 15% to 25% smaller than GZIP at comparable settings. But the gap between GZIP and Brotli compression is smaller than most tutorials suggest, and picking the wrong compression level can cost you more in server CPU than you gain in transfer size. Here’s how the two actually compare, and how to configure whichever one your host supports.

What text compression actually does

When a browser requests a page, it sends an Accept-Encoding header listing the formats it can decode. Your server picks one, compresses the response, and returns a Content-Encoding header so the browser knows how to unpack it. The whole exchange is described in the MDN documentation on Content-Encoding.

Compression only helps with text-based files. HTML, CSS, JavaScript, JSON, SVG and XML all contain enormous amounts of repetition, which is exactly what these algorithms exploit. JPEGs, PNGs, MP4s and WOFF2 fonts are already compressed, so running them through GZIP again wastes CPU and occasionally makes the file slightly larger.

GZIP: the format everything supports

GZIP has been around since 1992 and is supported by every browser, proxy, CDN and command-line tool you will ever encounter. It uses DEFLATE with a 32 KB sliding window, and on a typical WordPress page it cuts HTML by 60% to 75%. That’s the bulk of the win right there.

Compression levels run from 1 to 9. Level 6 is the common default and sits in a reasonable spot; level 9 buys you maybe 1% to 2% more savings for noticeably more CPU per request. If you are still serving uncompressed text in 2026, enabling GZIP is the single cheapest speed improvement available to you.

Brotli: newer, denser, more tunable

Brotli was released by Google in 2015 and standardised as RFC 7932. It improves on GZIP in two ways: a much larger sliding window (up to 16 MB) and a built-in dictionary of around 13,000 common web strings, including fragments of HTML tags, CSS properties and JavaScript keywords. Because WordPress output is full of those exact strings, Brotli compression tends to pull ahead on small files where GZIP barely gets warmed up.

Brotli’s quality scale runs 0 to 11, which is where people get into trouble. Level 11 produces the smallest files but can be 10 to 50 times slower to compress than GZIP level 6, so it is only appropriate for static assets compressed once and cached.

Head to head: what the numbers usually look like

Results vary by theme and plugin stack, but on a typical WordPress install the pattern is consistent:

• HTML: a 120 KB page drops to roughly 22 KB with GZIP level 6 and about 18 KB with Brotli level 5, so Brotli offers around 18% better compression.
• CSS: Brotli usually beats GZIP by 15% to 20% on large stylesheets.
• JavaScript: the smallest gap, often 8% to 14%, since minified JS is already dense.
• SVG and JSON: Brotli frequently wins by 20% or more, which matters for REST API responses and block editor payloads.

In real-world terms, that 4 KB difference on an HTML document is worth perhaps 20 to 60 milliseconds on a slow mobile connection. Real, measurable, but not the thing that will fix a three-second load time.

The tradeoff most articles skip: CPU and TTFB

Here’s the part that gets glossed over. WordPress HTML is generated per request unless it is fully page-cached, which means it has to be compressed per request too. Every millisecond spent compressing is a millisecond added to Time to First Byte.

On a busy site, aggressive dynamic Brotli settings can push CPU load up sharply without a visible speed win. We’ve seen shared and entry-level VPS accounts flagged for load spikes that traced straight back to brotli_comp_level 9 or higher on dynamic output. If your load average climbs after enabling compression, our guide on how to debug high CPU usage on your WordPress server walks through isolating the cause.

Sensible defaults look like this:

• Dynamic HTML (uncached): Brotli level 4 or 5, or GZIP level 5 to 6.
• Static CSS, JS, SVG: pre-compress at Brotli level 11 and store the .br file on disk.
• API and AJAX responses: Brotli level 4, since these are small and latency-sensitive.
• Images, video, fonts, ZIP archives: skip compression entirely.

How to enable GZIP or Brotli on WordPress

The method depends on your web server, and on managed platforms the whole thing may already be handled for you.

Apache

Use mod_deflate for GZIP, adding AddOutputFilterByType DEFLATE text/html text/css application/javascript application/json image/svg+xml to your config or .htaccess. Brotli requires mod_brotli, compiled in on Apache 2.4.26 and later.

Nginx

GZIP is built in: set gzip on;, then define gzip_types and gzip_comp_level 5;. Brotli needs the ngx_brotli module compiled against your Nginx build, then brotli on; plus brotli_static on; to serve pre-compressed files when they exist.

LiteSpeed and OpenLiteSpeed

Brotli support ships in the server itself, and the caching layer handles static pre-compression automatically. Sites running LiteSpeed Cache generally get Brotli for static assets and GZIP or Brotli for cached HTML with no manual configuration.

Plugins and CDNs

A plugin can toggle GZIP rules in .htaccess, but no PHP plugin can add real Brotli support to a server that lacks the module. The practical shortcut is a CDN: Cloudflare, Fastly and most edge networks negotiate Brotli with the browser regardless of your origin. That interacts with your caching strategy, which we cover in our comparison of edge caching versus traditional CDNs.

How to check GZIP or Brotli compression is working

Verification takes about thirty seconds. Open Chrome DevTools, go to the Network tab, click a document request and read the Content-Encoding response header: br means Brotli, gzip means GZIP compression is detected, and nothing means you are shipping raw text.

From a terminal, run curl -sI -H "Accept-Encoding: br,gzip" https://yoursite.com and read the headers. Any online compression checker works too, and PageSpeed Insights flags uncompressed text under “Enable text compression” with the exact kilobytes you would save.

What compression will not fix

Compression shrinks bytes on the wire. It does nothing for slow database queries, bloated plugin stacks, unoptimised images or render-blocking scripts. A 4 KB saving on HTML is irrelevant if your homepage loads 3 MB of hero imagery and eleven third-party trackers.

Treat compression as table stakes and spend your remaining effort on caching, PHP version, image formats and query efficiency. Membership sites and course platforms feel this most, because logged-in traffic bypasses page caching entirely and every response is compressed fresh. That’s why hosting built for membership sites tunes dynamic compression conservatively and leans harder on object caching. For a straightforward content site, managed WordPress blog hosting with full-page caching makes the compression question mostly academic.

If you run self-hosted WordPress on your own stack, you own these settings, so document your levels and re-test after every server upgrade. Teams running decoupled front ends should also read our take on headless versus traditional WordPress architecture, since JSON payload compression behaves differently there.

Frequently Asked Questions

Is Brotli compression better than gzip?

Yes, Brotli typically produces files 15% to 25% smaller than GZIP on HTML and CSS at comparable speed settings. The advantage comes from its larger window and web-specific dictionary. GZIP remains better in one respect: universal support and much lower CPU cost at high compression levels.

What is the best image compression plugin for WordPress?

ShortPixel, Imagify and EWWW Image Optimizer are the three most widely used, each handling WebP and AVIF conversion at scale. Note that image compression is a separate process from GZIP or Brotli, which should never be applied to image files. Serving modern formats usually saves far more bandwidth than any text compression change.

Should I use Brotli?

Use Brotli if your server or CDN supports it, since every browser released since about 2016 accepts it over HTTPS. Keep GZIP enabled as the fallback, which servers handle automatically through content negotiation. Set dynamic compression to level 4 or 5 and reserve level 11 for pre-compressed static assets.

What is the most efficient compression format?

For web text, Brotli at quality 11 gives the smallest output, commonly 20% to 26% below GZIP level 9. Zstandard (zstd) is gaining browser support and compresses far faster at similar ratios, so it is worth watching over the next couple of years.

Want compression handled for you?

Every WebVibo plan ships with Brotli, GZIP fallback and pre-compressed static assets configured at sensible levels, so you are not editing Nginx configs at midnight. Start a free trial or ask our team to audit your current compression setup.