Gzip & Brotli Compression Tester
Verify if your server serves compressed assets (Brotli/Gzip), measure size reduction, and identify missing caching headers.
Understanding HTTP Compression
📌 On this page
1. How HTTP compression negotiation works
When a browser requests a page, it sends an Accept-Encoding header listing which compression algorithms it can decode (typically gzip, deflate, br, and increasingly zstd). The server picks one it supports, compresses the response body, and returns it with a Content-Encoding header telling the browser which algorithm was used. The browser decompresses automatically before rendering — this negotiation is invisible to end users but represents one of the largest "free" bandwidth savings available on the modern web, since text compresses extremely well.
2. Gzip vs. Brotli vs. Zstandard
Gzip has been the universal baseline since the late 1990s and remains supported everywhere. Brotli, developed by Google and standardized in 2016, generally achieves 15-25% smaller output than gzip on the same text content because of a more sophisticated compression algorithm and a built-in dictionary tuned for common web content patterns (HTML tags, CSS properties, JavaScript keywords). Zstandard (zstd), originally from Facebook, offers extremely fast compression/decompression speed and is gaining browser and CDN support, though it's the least universally available of the three as of today.
3. Why the Vary header matters for CDNs
A CDN or intermediate proxy cache can serve the same URL to millions of different clients, some of which support Brotli, some only gzip, and rare legacy clients that support neither. Without a Vary: Accept-Encoding header, a cache might store one compressed variant and serve it to a client that can't decode it (breaking the page), or serve an uncompressed variant to every client regardless of capability (wasting bandwidth for everyone who could have received a smaller file). The Vary header tells caches to store separate copies per encoding, so each visitor gets the right variant.
4. Enabling compression on common WordPress stacks
On Apache, mod_deflate (gzip) or mod_brotli directives in .htaccess handle this — most managed WordPress hosts enable it by default, but self-managed VPS setups sometimes don't. On Nginx, it's the gzip and brotli directives in the server or http block. If your site sits behind a CDN like Cloudflare, compression is typically handled automatically at the edge regardless of your origin server's configuration, which is one reason a CDN-fronted site often passes this test even when the origin server itself has compression disabled.
5. What should (and shouldn't) be compressed
Text-based formats — HTML, CSS, JavaScript, JSON, XML, SVG, plain text — compress extremely well (often 60-80% smaller) and should always be compressed. Already-compressed binary formats — JPEG, PNG, WebP, AVIF, MP4, WOFF2 fonts, ZIP archives — gain little to nothing from further gzip/Brotli compression since their internal format is already entropy-coded, and attempting to compress them wastes CPU cycles for no benefit. A well-configured server applies compression selectively by MIME type rather than blanket-compressing every response.
6. Compression's real impact on Core Web Vitals
Smaller HTML means faster parsing and earlier First Contentful Paint. Smaller CSS means render-blocking stylesheets resolve faster, directly helping Largest Contentful Paint. Smaller JavaScript bundles download and parse faster, indirectly helping Interaction to Next Paint by reducing main-thread congestion during page load. None of these effects are dramatic in isolation on a fast connection, but compound meaningfully on slower mobile networks — which is exactly the segment where Core Web Vitals thresholds are hardest to hit and matter most for real-world user experience.
Frequently Asked Questions
What is the difference between Gzip and Brotli (br)?
Brotli is a newer compression algorithm created by Google that achieves 15–25% smaller file sizes than standard Gzip on CSS, JavaScript, and HTML assets. Both are supported in 98%+ of modern browsers.
Why is the Vary: Accept-Encoding header important?
The Vary: Accept-Encoding header informs intermediate proxy caches, CDNs, and browser caches that response representations differ based on the client compression capabilities, preventing uncompressed caches from being served to modern browsers.
How does text compression improve Core Web Vitals?
Compressing text resources reduces total page transfer weight directly affecting Time to First Byte (TTFB), First Contentful Paint (FCP), and Largest Contentful Paint (LCP) by freeing network bandwidth for render-critical assets.
How do I enable Gzip or Brotli on WordPress?
On Apache servers, add mod_deflate rules in your .htaccess file (you can generate this using our .htaccess Generator). On Nginx, add "gzip on;" or "brotli on;" to your server block. Most modern CDNs like Cloudflare handle Brotli automatically.
How does this tool actually measure the compression savings?
It makes two real HTTP requests to your URL: one sending an Accept-Encoding header requesting gzip/deflate/br/zstd (matching what a real browser sends), and one sending Accept-Encoding: identity to request the raw, uncompressed response. It compares the actual byte sizes of both real responses to calculate the savings percentage — this is a genuine before/after measurement, not a guess, except in the rare case where a server ignores the identity request and a size-based fallback estimate is used instead.
My server shows "Compression Disabled" — is that always bad?
For text-based resources (HTML, CSS, JavaScript, JSON, SVG), yes — compression is a near-zero-cost, high-value optimization that virtually every modern web server supports. It's expected and fine, however, for already-compressed binary formats like JPEG, WebP, AVIF, MP4, or ZIP files, since compressing already-compressed data wastes CPU for negligible or even negative savings. If this tool is flagging your HTML page itself as uncompressed, that's worth fixing; if you're testing an image URL directly, a "disabled" result there is normal and expected.
What does the "Est. 4G Time Saved" figure actually represent?
It converts the measured byte savings into an estimated transfer-time reduction assuming a 15 Mbps download connection, which is a reasonable approximation of a typical 4G mobile connection. Real-world savings will vary with the visitor's actual connection speed, network congestion, and latency — treat this figure as a relatable way to understand the byte savings, not a guaranteed number for every visitor.