Five sites in 428 serve HTML uncompressed. Which algorithm the rest use was decided by their platform

The belief this was meant to confirm

We had a sentence written down: the most common gap between a site and its accelerated version is that the origin ships its text uncompressed. It came from one site. Ours. We had turned on Brotli on our own shared host, watched what happened, and generalised from a sample of one without noticing that we had.

So the study was set up to put a denominator under it, and the denominator retired the claim.

Asking 441 sites

An audit stores what a page loaded and how fast; it does not store the response headers, so this could not be answered from what we already had. We asked again — one request per host, sent as a browser sends it, offering every encoding a current Chrome offers.

What came back	Sites	Share
gzip	226	53%
Brotli (br)	157	37%
Zstandard (zstd)	32	7%
Nothing at all	13	3%

And the thirteen do not hold up as a group. Eight of them returned exactly 114 bytes: parked domains that arrived in our base from a domain list, serving a placeholder. Compression is not a meaningful concept for a 114-byte document, and Lighthouse agrees in its own thresholds — if the original size of a response is less than 1.4KiB … Lighthouse does not flag that response.

Five real pages remain. They are worth naming as a class rather than as sites: two of them are single-page applications served from object storage, one is a 300 KB HTML document behind a CDN that was not asked to compress it, and the largest three ship between 85 KB and 300 KB of markup raw. That is the shape of the problem in 2026 — not a widespread default, but a misconfiguration that survives precisely because everything else about the setup looks modern.

The median HTML document in this sample is 43 KB before compression. Uncompressed, that is roughly a second of a slow mobile connection spent on text; compressed, it is a fraction of one. The reason nobody sees this problem any more is that it was solved by defaults, not by diligence.

The part that does vary

Splitting the same 428 responses by platform turns a boring answer into a structural one.

Platform	Sites	What they answered with
Wix	28	Brotli, 28 of 28
Squarespace	35	gzip, 35 of 35
Tilda	33	gzip, 33 of 33
Duda	44	gzip, 43 of 44
Webflow	33	gzip 30, zstd 2, none 1
WordPress + WooCommerce	111	br 67, gzip 28, zstd 16

Five of those rows are decisions taken once, by a platform, for everybody on it. A Wix site gets Brotli because Wix serves Brotli; a Squarespace site gets gzip for the same reason in reverse. No setting in either editor changes it, and no amount of care from the site owner enters into it.

The WordPress row is the only one that splits, and it splits because there is somebody to make the choice: a host, a CDN in front of it, or a plugin. Sixty percent land on Brotli, a quarter are still on gzip, and one in seven is already on Zstandard, which Chrome only started accepting in Chrome 123. Self-hosting is the only column here where the answer is a property of the site rather than of the brand above it.

What this changes about reading a slow site

Three practical consequences, and the first one is the one we got wrong.

Compression is no longer a diagnosis. If a site is slow and you are looking for the reason, the odds that raw text is it are about one in eighty, and lower than that if the page is a real page rather than a stub. Checking is one request and costs nothing, which is exactly why it should be checked and then dropped rather than assumed either way.

Which algorithm is a smaller question than it sounds. We have one document measured both ways: compressing the stored HTML of a page in our base gave 83,787 bytes under gzip −9 and 65,433 under brotli −11, a fifth smaller. Worth having, and a fifth of the text is not what stands between that page and a faster one. On a shared host the compression level you can afford at request time can also turn the win into a loss, which is what our own site taught us before we generalised from it.

If your platform chose for you, this is not your line item. On five of the six groups above the encoding is a fact about the vendor. The useful reading of that table is not “which is best” but “how much of your page’s delivery is a decision you are allowed to make” — and on a hosted builder, less of it than the tooling implies.