Compression mix
Text-response compression across requests: brotli, gzip, zstd, or none.
At a glance the headline numbers for Compression mix
Text-response compression across requests: brotli, gzip, zstd, or none.
25.5% of text responses use Brotli. 49.6% ship uncompressed.
The compression mix mix who uses what, and how fast each group loads
Compression mix. On the fleet: 49.6% none, 25.5% br, 21.7% gzip. 99.6% of sites use at least one none.
None leads by count (49.6%) and by bytes (80.1%). computed
Passing INP per bucket every category and count level at once - color is the pass rate
Each row is a category, each column its own count bucket (few on the left, many on the right); the cell is the share of those sites passing INP.
No category moves the INP pass rate much, however many a site ships. computed
Few vs many - does quantity cost INP? the pass rate with few vs many of each category
Per category: the pass rate among pages with FEW of it (hollow ring) against pages with MANY (solid dot), worst trend first. Thin buckets are excluded from the endpoints.
More Br costs the most: the INP pass rate falls from 99% with few to 98% with many. computed
Why this matters for the Core Web Vitals, and where to start fixing it
HTML, CSS, JavaScript, SVG and JSON shrink to a fraction of their size with gzip or brotli. Every CDN can apply it at the edge. An uncompressed HTML document delays the TTFB. An uncompressed stylesheet delays rendering, and with it the LCP.
Compression cuts transfer time, not execution time. A compressed JavaScript bundle still costs the same CPU to parse and run, so compression helps TTFB and LCP, not INP. Also check the right files: images, video and woff2 fonts are already compressed. The gains are in your text responses.
How does this affect the Core Web Vitals?
Compression mix correlates with the LCP. With Dcb, 97% of sites pass the LCP. With Zstd, 85% do.
Chrome field data from 94,910 sites, representing millions of real page loads. How we measured.