HTML Compression/GZIP Test
What is it?
HTML compression is the practice of having your server transmit HTML responses in a compressed format such as Gzip or Brotli, with the browser decompressing them on receipt. Compressed text responses are typically 60 to 80 percent smaller than uncompressed ones, with negligible decompression cost, which translates directly into faster page loads, especially on slower connections and high-latency mobile networks.
Why HTML compression still matters
Compression is one of the cheapest performance wins on the web. Enabling it requires no code changes, no design work, and no asset re-engineering, just a server or CDN configuration setting. Yet sites that miss it pay the cost on every single page load, multiplied by every visitor on every device. The Core Web Vitals impact is real but the bigger story is bandwidth: users on metered or slow connections see meaningfully faster pages and lower data charges with compression enabled.
Modern best practice is to use Brotli when the client supports it, falling back to Gzip otherwise. Brotli compresses text formats roughly ten to twenty percent better than Gzip with comparable decode speed, and is supported by every browser released in the last several years. Most modern CDNs and web servers handle the negotiation automatically.
Common reasons compression is disabled
- Compression not enabled at all on the web server or CDN.
- Compression bypassed for the HTML MIME type: some configurations compress only specific MIME types, accidentally skipping
text/html. - CDN caching the uncompressed response after compression was enabled, requiring a cache purge to take effect.
- Server explicitly setting
Content-Encoding: identity, which tells clients no compression is in use.
This test verifies that your server delivers the HTML response in a compressed format. The fix guide below covers enabling Gzip and Brotli on the major web servers and CDN platforms, and verifying that the response includes the expected Content-Encoding header.
Pass rate:
-
Top 100 websites: %This value indicates the percent of top 100 most visited websites in the US that pass this test (in the past 12 months).
-
All websites: 94%This value indicates the percent of all websites analyzed in SEO Site Checkup (500,000+) in the past 12 months.
| 2021 | 96% |
|---|---|
| 2022 | 97% |
| 2023 | 97% |
| 2024 | 99% |
100
75
50
25
0
How do I fix it?
This test fails when the server delivers HTML uncompressed. Compressing responses with Gzip or Brotli typically shrinks the transfer size by sixty to eighty percent with negligible decompression cost, which translates directly into faster page loads, especially on slower connections. Fixing this issue is usually a server or CDN configuration change rather than a code change.
Where to make the change
- Server configuration: enable compression in your web server. For Nginx use
gzip on;(and thebrotlimodule); for Apache usemod_deflateormod_brotli; for IIS enable Dynamic Compression. - Cloud platforms: most modern hosts (Cloudflare, Netlify, Vercel, AWS CloudFront, Fastly) compress text responses automatically. Confirm it is enabled in the dashboard.
- Application server: Node, Python, and Ruby app servers can compress responses themselves (for example
compressionmiddleware in Express). Compressing at the edge or web server is preferable to keep app servers focused on rendering.
Common causes and how to resolve them
- Compression not enabled: turn it on at the server or CDN level. Verify with a tool such as DevTools Network panel by checking for the
content-encodingresponse header. - Compression bypassed for HTML MIME type: some configurations compress only specific MIME types. Confirm
text/htmlis included in the allowed list. - CDN caching the uncompressed response: purge the cache after enabling compression so cached entries get regenerated.
- Server sets
Content-Encoding: identity: this disables compression. Remove or update the directive.
Best practices
- Prefer Brotli over Gzip: Brotli compresses HTML, CSS, and JavaScript ten to twenty percent better than Gzip with comparable decode speed.
- Enable for all text content: apply compression to HTML, CSS, JavaScript, JSON, SVG, and XML responses. Skip it for already-compressed assets such as images and video.
- Verify in production: the response header
content-encoding: brorcontent-encoding: gzipconfirms compression is live.