Uncompressed text responses on React sites
57.9% of audited sites (5,544) ship at least one uncompressed text resource (85% good LCP, 1.4s median), trailing sites that compress every text response (42.1%, 84% good LCP, 1.4s median).
57.9% of React sites use uncompressed text responses text compression coverage, and 85% of those sites have a good LCP, against 84% of all React sites.
LCP pass rate
Sites with uncompressed text responses text compression coverage have a good LCP most often: 85%, against 84% of all React sites. Sites with full text compression text compression have it least often, at 84%.
Text compression coverage usage
Uncompressed text responses is the most used: 57.9% of React sites.
How leaking uncompressed text responses affects the four LCP phases
Across the four LCP sub-parts in Chrome's field data, the largest gap between uncompressed text responses and full text compression sits in resource load delay: 467 ms median for uncompressed text responses against 392 ms for full text compression. Overall median field LCP is 1.4s for uncompressed text responses (TTFB 482 ms, load delay 467 ms, load duration 128 ms, render delay 173 ms) versus 1.4s for full text compression.
Text compression coverage per platform
Wix sets the text compression coverage to uncompressed text responses on 61% of its sites, and 94% of Wix sites have a good LCP, against 84% of all sites. WordPress sets the text compression coverage to full text compression on 59% of its sites, and 63% of WordPress sites have a good LCP.
Wix 5,824 sitesHas uncompressed text 61%All text compressed 39%94%
WordPress 2,342 sitesAll text compressed 59%Has uncompressed text 41%63%Uncompressed text responses or the platform
Does the platform explain the text compression coverage difference?
On Wix, 93% of sites with uncompressed text responses text compression coverage have a good LCP, against 96% of Wix sites with full text compression. Within Wix, sites with uncompressed text responses have a good LCP less often. On WordPress, 60% of sites with uncompressed text responses text compression coverage have a good LCP, against 65% of WordPress sites with full text compression. Within WordPress, sites with uncompressed text responses and full text compression have a good LCP about equally often.
Where uncompressed text responses slip through on modern web stacks
Almost no server intentionally disables compression globally. Instead, uncompressed text responses slip through narrow MIME-type allowlists (forgetting image/svg+xml or application/json in nginx or Apache) or come from third-party API and widget endpoints that bypass the primary CDN. Across 4,026 sites (42.1%) that compress every text response, good LCP reaches 84% (1.4s median, 541 ms TTFB), whereas the 5,544 sites (57.9%) shipping at least one uncompressed text payload drop to 85% good LCP (1.4s median, 482 ms TTFB).
Understanding uncompressed text responses
Enable Brotli or gzip across every compressible MIME type on both your origin server and CDN edge: text/html, text/css, application/javascript, application/json, image/svg+xml, and font/ttf. Text resources shrink by 70% to 85% when compressed; leaving a render-blocking stylesheet, SVG hero, or hydration JSON payload uncompressed multiplies wire transfer time on mobile networks. Across the dataset, 42.1% of sites compress all text responses (84% good LCP, 1.4s median) while 57.9% ship at least one uncompressed text file (85% good LCP, 1.4s median).
By Arjen Karel · 9,570 crawled React sites (5,488 with phone Chrome field data, October 2026). How we measured.