HTML document compression on React sites

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

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): 437 ms median for Brotli against 545 ms for no. Overall median field LCP is 1.2s for Brotli (TTFB 437 ms, load delay 441 ms, load duration 118 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 84% of all sites.

PlatformHTML compression on its sitesGood LCP

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

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

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

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 96% of Wix sites with no. Within Wix, sites with Brotli and no have a good LCP about equally often. On WordPress, 71% of sites with Brotli HTML compression have a good LCP, against 57% 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 437 ms median TTFB and 1.2s median LCP, compared with 1034 ms TTFB and 2.0s LCP on Gzip.