WordPress GZIP and Brotli Compression: What They Are and How to Enable Them

If you’ve ever run your WordPress site through Google PageSpeed Insights or GTmetrix and seen a warning like “Enable text compression,” this guide is for you. HTTP compression is one of the most impactful and underappreciated performance optimizations available — and in most cases, enabling it requires no changes to your WordPress theme, plugins, or database.

This post explains how GZIP and Brotli compression work, how to verify whether your site is using them, and how to enable them if it isn’t.

What Is HTTP Compression?

When your browser requests a page from your WordPress server, the server can compress the response before sending it. The browser receives a smaller file, decompresses it locally, and renders the page. This process is transparent to the user but can dramatically reduce the amount of data transferred over the network.

The two compression formats used for HTTP responses are:

• GZIP — the long-standing standard, supported by virtually every web server and browser since the early 2000s
• Brotli — a newer algorithm developed by Google and released in 2015, supported by all modern browsers and offering better compression ratios than GZIP on most content types

Both formats work on text-based content: HTML, CSS, JavaScript, JSON, XML, and SVG files. They are not used for already-compressed formats like JPEG, PNG, WebP, or ZIP files, where re-compression would produce no benefit and might even slightly increase file size.

How Much Does Compression Help?

The compression ratio depends on the content being compressed. Text with repetitive patterns — which describes most HTML, CSS, and JavaScript — compresses particularly well.

For a typical WordPress page:

• HTML: Often compresses to 20–30% of its original size
• CSS: Often compresses to 15–25% of its original size
• JavaScript: Often compresses to 25–40% of its original size

An uncompressed WordPress HTML page might weigh 80–120KB. With GZIP enabled, the same page might be 20–35KB over the wire. With Brotli, it may compress slightly further still.

For users on slower connections or mobile networks, this reduction in transfer size translates directly to faster load times. For users on fast connections, compression reduces server-side bandwidth usage and can lower time-to-first-byte when combined with efficient server configuration.

GZIP vs. Brotli

GZIP uses the deflate compression algorithm and has been the web standard for HTTP compression since the late 1990s. It is supported by essentially every web server, CDN, and browser in existence.

Brotli uses a different algorithm that combines LZ77 compression, Huffman coding, and second-order context modeling. In practice, Brotli typically achieves 15–25% better compression than GZIP on web assets like HTML and JavaScript, according to benchmarks published by Google when the format was introduced.

Brotli is supported by all modern browsers — Chrome, Firefox, Safari, and Edge — but requires HTTPS, as browsers only advertise Brotli support on secure connections. It is also supported by major CDNs including Cloudflare, Fastly, and Amazon CloudFront.

For most WordPress sites, the practical choice is: use Brotli if your server or CDN supports it, and fall back to GZIP for clients that don’t. Modern managed hosting and CDN stacks handle this negotiation automatically.

How to Check if Compression Is Active on Your Site

Using a Browser DevTools

1. Open Chrome DevTools (F12 or Cmd+Option+I on Mac)
2. Go to the Network tab
3. Load or refresh your WordPress homepage
4. Click on your main HTML document in the request list
5. Look at the Response Headers section for content-encoding

If you see content-encoding: gzip or content-encoding: br, compression is active. The br value indicates Brotli. If the header is absent, the response is not being compressed.

You can repeat this check for your main CSS and JavaScript files, which should also be compressed.

Using an Online Tool

Tools like GiftOfSpeed’s GZIP Test allow you to enter your URL and see whether GZIP is active, along with the original vs. compressed file sizes. Similar tools exist for Brotli testing.

Checking PageSpeed Insights

Google PageSpeed Insights flags uncompressed text resources under the “Enable text compression” audit. If this audit appears with specific files listed, those files are being served without compression.

How to Enable GZIP Compression on WordPress

The method depends on your web server. Compression is configured at the server level, not within WordPress itself — which is why you generally cannot enable it by adding PHP code to your theme.

On Apache (.htaccess)

If your WordPress site runs on Apache and you have access to .htaccess, you can enable GZIP compression by adding the following before the existing WordPress rewrite rules:

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

This requires mod_deflate to be loaded on your Apache installation. Most shared and managed Apache configurations include it.

On Nginx

For Nginx, compression is typically enabled in the server configuration file (not accessible on most managed hosting plans). A basic configuration looks like:

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

Brotli on Nginx requires the ngx_brotli module, which is compiled separately and is not included in the default Nginx distribution. On managed WordPress hosts and CDNs, this is typically handled for you.

Using a WordPress Plugin

If you don’t have server configuration access (common on shared hosting), some WordPress caching and performance plugins can enable GZIP at the PHP level:

• W3 Total Cache includes a browser cache tab with a GZIP option that writes the appropriate .htaccess rules
• WP Rocket can enable compression via its “Browser Caching” settings on compatible hosting

Note that plugin-based GZIP compression via PHP (ob_start('ob_gzhandler')) is less efficient than server-level compression and should be seen as a fallback when server configuration isn’t available.

CDN-Level Compression

If your WordPress site sits behind a CDN, the CDN may handle compression regardless of your origin server’s configuration. Cloudflare, for example, enables GZIP compression by default on all plans and supports Brotli compression on all plans as well.

When a CDN is in front of your origin, the CDN sends the compressed response to the browser even if your origin server sends an uncompressed response. The origin-to-CDN leg of the request is typically a fast datacenter connection where compression matters less.

Common Issues and Pitfalls

Double compression: If your origin server compresses responses and your CDN also applies compression, the CDN typically detects the content-encoding header and serves the already-compressed content as-is. In practice, double-compression is not a common problem, but it’s worth checking that your CDN and server aren’t both compressing the same content and causing unexpected behavior.

Already-compressed file types: Applying GZIP or Brotli to JPEG, PNG, WebP, MP4, or ZIP files wastes CPU time and can slightly increase file size. Properly configured servers exclude these types from compression, as shown in the Apache example above.

Minimum file size thresholds: Very small files (under 1KB) may not benefit meaningfully from compression, since the compression overhead can exceed the gains. The gzip_min_length directive in Nginx addresses this; similar options exist in Apache.

Caching compressed responses: When compression is enabled, your server’s caching layer (or CDN) should cache the compressed version of each response rather than the uncompressed version. Serving compressed cached files avoids the CPU cost of compressing on every request.

Does Your Hosting Handle This Automatically?

On well-configured managed WordPress hosting, GZIP and Brotli compression are enabled at the server level with no action required from you. When you sign up and install WordPress, compression is already active for HTML, CSS, JavaScript, and other text content.

This is one of the many infrastructure details that managed hosting handles automatically — alongside server-side page caching, HTTP/2 support, PHP optimization, and CDN integration. For WordPress site owners who want fast load times without digging into server configuration files, the hosting layer is where most of these baseline performance settings are determined.

If you’re on shared hosting and finding that compression isn’t active, you’re either dealing with a host that hasn’t enabled mod_deflate, or you need to add the .htaccess rules described above. If that still doesn’t work, it may be worth evaluating whether your current hosting environment is configured for WordPress performance.

---

Rocket.net is a managed WordPress hosting provider that handles server-level compression, page caching, and CDN delivery as part of its standard infrastructure — so these optimizations are active for every site hosted on the platform. If you’re evaluating managed WordPress hosting options, you can learn more about Rocket.net here.