HTML document compression on React sites

Sites with Brotli HTML compression have a good LCP most often: 86%, against 79% of all React sites. Sites with Gzip HTML compression have it least often, at 70%.

Nine in ten React sites uses HTML compression, and four in five of those use Brotli.

Across the four LCP sub-parts in Chrome's field data, the largest gap between Brotli and no sits in time to first byte (TTFB): 477 ms median for Brotli against 620 ms for no. Overall median field LCP is 1.4s for Brotli (TTFB 477 ms, load delay 469 ms, load duration 199 ms, render delay 162 ms) versus 1.7s for no.

Wix sets the HTML compression to Brotli on 97% of its sites, and 92% of Wix sites have a good LCP, against 79% of all sites.

PlatformHTML compression on its sitesGood LCP

All React sites 9,570 sitesBrotli (br) 71%Gzip 18%79%

Wix 5,824 sitesBrotli (br) 97%92%

WordPress 2,342 sitesGzip 48%Brotli (br) 36%66%

Brotli (br) Gzip Uncompressed (none) Zstandard (zstd)

Does the platform explain the HTML compression difference?

On WordPress, 67% of sites with Brotli HTML compression have a good LCP, against 59% of WordPress sites with no. Within WordPress, sites with Brotli and no have a good LCP about equally often.

Why Brotli HTML compression speeds up resource discovery

Brotli uses a built-in dictionary of common HTML, CSS, and JavaScript tokens, shrinking HTML documents 15 to 20 percent more than Gzip at comparable CPU cost. Because the browser's preload scanner parses the HTML stream chunk by chunk as it arrives, a smaller compressed document delivers the <head> and hero <img> markup in fewer TCP or QUIC packets. Sites serving Brotli HTML record a 477 ms median TTFB and 1.4s median LCP, compared with 1016 ms TTFB and 1.8s LCP on Gzip.