HTML document compression on React sites

Sites with Brotli HTML compression have a good LCP most often: 91%, against 85% of all React sites. Sites with Zstandard HTML compression have it least often, at 65%.

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 resource load delay: 450 ms median for Brotli against 368 ms for no. Overall median field LCP is 1.3s for Brotli (TTFB 453 ms, load delay 450 ms, load duration 142 ms, render delay 160 ms) versus 1.5s for no.

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

PlatformHTML compression on its sitesGood LCP

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

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

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

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

Does the platform explain the HTML compression difference?

On Wix, 94% of sites with Brotli HTML compression have a good LCP, against 94% of Wix sites with no. Within Wix, sites with Brotli and no have a good LCP about equally often. On WordPress, 70% of sites with Brotli HTML compression have a good LCP, against 54% of WordPress sites with no. Within WordPress, sites with Brotli have a good LCP more 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 453 ms median TTFB and 1.3s median LCP, compared with 1071 ms TTFB and 2.0s LCP on Gzip.