Uncompressed text responses on React sites
57.9% of audited sites (5,544) ship at least one uncompressed text resource (78% good LCP, 1.6s median), trailing sites that compress every text response (42.1%, 80% good LCP, 1.5s median).
42.1% of React sites use full text compression text compression coverage, and 80% of those sites have a good LCP, against 79% of all React sites.
LCP pass rate
Sites with full text compression text compression coverage have a good LCP most often: 80%, against 79% of all React sites. Sites with uncompressed text responses text compression have it least often, at 78%.
Text compression coverage usage
Uncompressed text responses is the most used: 57.9% of React sites. Full text compression is 42.1% 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 full text compression and uncompressed text responses sits in resource load delay: 363 ms median for full text compression against 469 ms for uncompressed text responses. Overall median field LCP is 1.5s for full text compression (TTFB 715 ms, load delay 363 ms, load duration 149 ms, render delay 197 ms) versus 1.6s for uncompressed text responses.
Text compression coverage per platform
WordPress sets the text compression coverage to full text compression on 59% of its sites, and 66% of WordPress sites have a good LCP, against 79% of all sites. Wix sets the text compression coverage to uncompressed text responses on 61% of its sites, and 92% of Wix sites have a good LCP.
Wix 5,824 sitesHas uncompressed text 61%All text compressed 39%92%
WordPress 2,342 sitesAll text compressed 59%Has uncompressed text 41%66%Uncompressed text responses or the platform
Does the platform explain the text compression coverage difference?
On Wix, 93% of sites with full text compression text compression coverage have a good LCP, against 92% of Wix sites with uncompressed text responses. Within Wix, sites with full text compression and uncompressed text responses have a good LCP about equally often. On WordPress, 70% of sites with full text compression text compression coverage have a good LCP, against 61% of WordPress sites with uncompressed text responses. Within WordPress, sites with full text compression and uncompressed text responses 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 80% (1.5s median, 715 ms TTFB), whereas the 5,544 sites (57.9%) shipping at least one uncompressed text payload drop to 78% good LCP (1.6s median, 693 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 (80% good LCP, 1.5s median) while 57.9% ship at least one uncompressed text file (78% good LCP, 1.6s median).
By Arjen Karel · 9,570 crawled React sites (1,979 with desktop Chrome field data, October 2026). How we measured.