Hosting & Server

Gzip and Brotli Compression

Intermediate
Medium

Text Compression Reduces Transfer Size

Gzip and Brotli are compression algorithms that reduce the size of text-based files — HTML, CSS, JavaScript, JSON, SVG, and XML — before they are sent from your server to the browser. The browser decompresses them automatically. Compression typically reduces text file sizes by 60–80%, which means a 200KB JavaScript file transfers as 40–60KB over the network. When compression is missing, every text-based resource takes significantly longer to download, directly affecting TTFB and overall page load time.

Mochyon Lightspeed detects this automatically. It checks whether your server is delivering compressed responses and flags when text compression is not enabled.

Gzip vs Brotli

Gzip has been the standard compression algorithm for the web since the late 1990s. It is universally supported by every browser and web server. Gzip at its default compression level provides a good balance of compression ratio and CPU cost.

Brotli is a newer algorithm developed by Google, specifically designed for web content. At comparable compression levels, Brotli produces files 15–25% smaller than Gzip. The trade-off is that Brotli compression (especially at higher levels) uses more CPU time than Gzip — but decompression in the browser is actually faster than Gzip. Brotli is supported by all modern browsers and is commonly available on current web servers.

In practice, the choice between Gzip and Brotli matters less than simply having compression enabled at all. The jump from no compression to Gzip is massive. The additional gain from Gzip to Brotli is meaningful but incremental.

What Gets Compressed

Compression applies to text-based content types: HTML documents, CSS stylesheets, JavaScript files, JSON responses, SVG images, and XML feeds. It does not meaningfully compress binary formats like JPEG, PNG, WebP, WOFF2 fonts, or video files — these are already compressed by their own encoding. Attempting to compress already-compressed files wastes CPU for negligible size reduction.

On a typical WordPress page, the compressible resources include the HTML document itself, all enqueued CSS and JavaScript files, any inline SVGs, and API responses. For a page with 500KB of combined CSS and JavaScript, compression reduces that to roughly 100–150KB of actual network transfer.

Why Compression Might Be Missing

Most modern hosting environments enable Gzip compression by default. However, it can be missing in several scenarios:

Misconfigured servers where compression modules are installed but not enabled for all text content types. Some server configurations only compress HTML but miss CSS and JavaScript.

Proxy or CDN misconfiguration where a CDN or reverse proxy sits between the origin server and the browser but does not pass through or apply compression correctly.

Self-managed servers where the administrator has not configured the web server’s compression module (mod_deflate for Apache, gzip module for Nginx, built-in compression for LiteSpeed).

How to Check

In browser DevTools, open the Network tab and look at the response headers for any CSS or JavaScript file. If you see Content-Encoding: gzip or Content-Encoding: br (Brotli), compression is working. You can also compare the “Size” column (transfer size) against the actual file size — if the transfer size is significantly smaller, compression is active.

Further Reading

Related Articles

Compression reduces the bytes transferred, which directly affects how quickly the first meaningful data reaches the browser.
Compression dramatically reduces the effective transfer weight of text resources, even when the uncompressed page weight is high.

Need help with this?

Mochyon specializes in WordPress Core Web Vitals optimization. We diagnose, fix, and verify — with a named human accountable for the result.

Get help from Mochyon