What is Gzip and Brotli Compression?

Gzip and Brotli are compression algorithms that your web server uses to shrink files before sending them to the visitor's browser. The idea is simple: text-based files like HTML, CSS, and JavaScript contain a lot of repetitive patterns, and compression algorithms are very good at finding and eliminating that redundancy. A 100 KB HTML file might compress down to 15-20 KB. The browser decompresses it instantly, and the visitor never notices anything except a faster page load.

If you have ever zipped a folder on your computer, you already understand the basic concept. Web compression works the same way, just automatically and transparently. The server compresses the response, the browser decompresses it, and neither the developer nor the visitor needs to do anything special (assuming the server is configured correctly).

How Web Compression Works at the Protocol Level

Every time a browser sends an HTTP request, it includes an Accept-Encoding header that tells the server which compression algorithms it supports:

Accept-Encoding: gzip, deflate, br

This header says the browser can handle Gzip, Deflate, and Brotli (abbreviated as br). The server picks the best algorithm it supports, compresses the response body, and adds a Content-Encoding header to tell the browser which algorithm was used:

Content-Encoding: gzip

or:

Content-Encoding: br

The browser reads this header, applies the corresponding decompression algorithm, and renders the content. If the server does not support compression (or if it is not configured), it sends the response uncompressed, and no Content-Encoding header is present.

This negotiation happens on every single request. The server can choose different compression methods for different file types, or even serve uncompressed content for files that do not benefit from compression.

Gzip: The Established Standard

Gzip has been the workhorse of web compression since the late 1990s. It is based on the DEFLATE algorithm (a combination of LZ77 and Huffman coding) and is supported by literally every browser and web server in use today. When people talk about "enabling compression" on a web server, they usually mean Gzip.

Gzip operates at configurable compression levels, typically ranging from 1 (fastest, least compression) to 9 (slowest, best compression). Most web servers default to level 6, which provides a good balance between compression ratio and CPU usage. At level 6, Gzip typically achieves 70-85% compression on text-based files. That means a 100 KB CSS file becomes roughly 15-30 KB.

The main advantages of Gzip are its universality (it works everywhere), its speed at moderate compression levels, and the decades of optimization that have gone into its implementations. The main disadvantage is that it does not compress quite as well as Brotli, especially for smaller files.

Brotli: The Modern Alternative

Brotli was developed by Google and published as RFC 7932 in 2016. It was specifically designed for web content and achieves 15-25% better compression ratios than Gzip on typical web assets. Brotli achieves this by using a more sophisticated compression algorithm and by including a built-in dictionary of common strings found in web content (HTML tags, CSS properties, JavaScript keywords, etc.).

Brotli also uses configurable compression levels, ranging from 0 to 11. At comparable quality levels, Brotli produces smaller output than Gzip, but at the highest levels (10-11), it is significantly slower to compress. This makes high-level Brotli compression ideal for static assets that can be pre-compressed once and served many times, but less suitable for dynamic content that needs to be compressed on every request.

One important limitation: Brotli only works over HTTPS. Browsers will not accept Brotli-compressed responses over plain HTTP connections. Since most WordPress sites should be on HTTPS anyway (and HTTP/2 requires it), this is rarely a practical concern.

Gzip vs. Brotli: A Practical Comparison

Here is how the two algorithms compare on metrics that matter for WordPress site owners:

• Compression ratio: Brotli typically produces files that are 15-25% smaller than Gzip at comparable compression levels. On a WordPress site that loads 500 KB of compressible assets, that difference translates to roughly 15-30 KB less data transferred per page load.
• Compression speed: Gzip at level 6 is faster than Brotli at an equivalent quality setting. For dynamic content (PHP-generated HTML pages), Gzip is often the more practical choice because the compression happens on every request. Brotli at levels 1-4 is comparable in speed to Gzip and still compresses somewhat better.
• Decompression speed: Brotli decompresses slightly faster than Gzip, which means the browser can process the content marginally quicker. The difference is small but consistent.
• Browser support: all modern browsers support both Gzip and Brotli. Internet Explorer (now discontinued) did not support Brotli, but Edge, Chrome, Firefox, and Safari all do. Global browser support for Brotli is above 96%.
• Server support: Apache supports Brotli through mod_brotli (available since Apache 2.4.26). Nginx supports it through the ngx_brotli module (a third-party module that needs to be compiled separately). LiteSpeed has built-in Brotli support. Most managed hosting providers and CDNs support both.
• HTTPS requirement: Brotli requires HTTPS. Gzip works over both HTTP and HTTPS.

In practice, many servers are configured to prefer Brotli when the browser supports it and fall back to Gzip otherwise. This gives you the best compression for modern browsers while maintaining compatibility with older clients.

How to Enable Compression in Apache

For Apache, you enable Gzip compression through mod_deflate (confusingly named, but it uses Gzip, not raw Deflate). Add the following to your .htaccess file:

  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/json
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE application/font-woff2

For Brotli on Apache, you need mod_brotli:

  AddOutputFilterByType BROTLI_COMPRESS text/html
  AddOutputFilterByType BROTLI_COMPRESS text/css
  AddOutputFilterByType BROTLI_COMPRESS text/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/javascript
  AddOutputFilterByType BROTLI_COMPRESS application/json

How to Enable Compression in Nginx

For Nginx, Gzip is built in and just needs to be enabled in the configuration:

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

For Brotli on Nginx, after installing the ngx_brotli module:

brotli on;
brotli_comp_level 6;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

WordPress Caching Plugins and Compression

If you do not have access to your server configuration (common on shared hosting), several WordPress caching plugins can handle compression for you:

• WP Rocket: enables Gzip compression automatically by adding rules to your .htaccess file. It also creates pre-compressed static HTML cache files.
• W3 Total Cache: offers Gzip compression as a configurable option in its Browser Cache settings. It can also serve pre-compressed files.
• LiteSpeed Cache: if your host runs LiteSpeed server, this plugin automatically enables both Gzip and Brotli compression.
• WP Super Cache: includes a Gzip compression option that compresses cached pages.
• Autoptimize: while primarily a CSS/JS optimization plugin, it can also serve compressed versions of the files it generates.

Keep in mind that if your server already handles compression at the server level, enabling it again through a plugin is unnecessary and can sometimes cause conflicts (double compression, which browsers cannot decompress).

Which File Types Benefit Most from Compression

Compression works best on text-based, repetitive content. Here is a breakdown by file type:

• HTML: compresses extremely well (70-90% reduction). WordPress-generated HTML pages are full of repetitive tag structures, class names, and whitespace.
• CSS: compresses very well (80-90% reduction). Stylesheets contain many repeated property names and selectors.
• JavaScript: compresses very well (70-85% reduction). JS files have repeated keywords, function names, and structural patterns.
• SVG: compresses extremely well (80-95% reduction). SVGs are XML-based and highly repetitive.
• JSON: compresses very well (75-90% reduction). API responses and configuration data benefit greatly.
• XML and RSS feeds: compress very well due to their repetitive tag structure.
• Web fonts (WOFF/WOFF2): WOFF2 fonts already include Brotli compression internally, so additional server-side compression provides minimal benefit. WOFF fonts include lighter compression and can benefit slightly from Gzip.

What Should NOT Be Compressed

Not all file types benefit from compression, and some should actively be excluded:

• JPEG, PNG, WebP, AVIF images: these formats are already compressed. Running them through Gzip or Brotli wastes CPU time and may even increase file size slightly.
• Video files (MP4, WebM): already compressed with highly efficient codecs. Server-side compression adds overhead for zero benefit.
• Audio files (MP3, AAC, OGG): same as video, already compressed.
• ZIP, GZIP, and other archives: already compressed by definition.
• PDF files: most PDFs use internal compression. Additional compression provides negligible savings.

Compressing already-compressed files wastes server CPU on every request and can even result in slightly larger output. Most web server configurations and WordPress caching plugins correctly limit compression to text-based MIME types, but it is worth verifying your setup to make sure binary files are excluded.

What InspectWP Checks

InspectWP examines the Content-Encoding response header returned by your WordPress site to determine whether compression is active. It specifically looks for gzip, br (Brotli), or deflate in the header value. If no compression is detected, the report flags this as a performance issue with a recommendation to enable either Gzip or Brotli compression. The detected compression method is displayed in the performance section of the report, giving you a clear view of whether your server is properly configured to reduce transfer sizes.