Brotli vs Gzip: Cloudflare Served My 344 Pages at Quality 4

Brotli at quality 11 shrank the 344 HTML pages on this blog to 18.0% fewer bytes than gzip at level 9. Visitors never get that version. I fetched 41 of those pages from picklog.cc three ways, and Cloudflare's Brotli came out 1.09% smaller than its gzip. For all 41 pages, the byte counts landed next to one local setting: quality 4. The docs say a Free-plan zone like mine gets Zstandard by default. I asked for zstd 41 times and got it 0 times.

This post covers brotli vs gzip on real, prose-heavy HTML: the full level sweep, what Cloudflare actually sends, and why I'm keeping quality 4 anyway.

The sweep: 344 pages, 34 settings

The input is every page the build writes to ops/site/blog/: 344 files, 9,103,623 bytes. Articles run from 14 to 38 KB, plus a 252 KB index. I compressed each file separately, the way a server would, with Python's gzip module, the brotli 1.2.0 binding and zstandard 0.25.0. Each timing is the fastest of five runs (three for the slowest levels). My first attempt called the brotli CLI once with every file on the command line and got 2,103 bytes at every quality. That was an error message, not compressed data, so I dropped the CLI and did everything in-process.

Three things in that table surprised me. First, Brotli's gains come in two jumps, not a smooth curve: q4 to q5 cuts 5.4%, then nothing much happens until q10 and q11. Second, zstd at 19 is still bigger than Brotli at 5 on this content. Brotli ships with a built-in dictionary of common web strings (RFC 7932, Appendix A), and on English prose wrapped in HTML that dictionary beats extra search effort. Third, Brotli's lowest qualities lose to gzip: q0 and q1 came out about 2% larger than gzip -1.

The cost side runs the other way. Brotli q11 took 5.9 seconds for the whole site, about 17 ms per page, which is 67 times gzip -9's time. That's a problem if a server compresses on every request and doesn't matter if a build does it once. Decompression isn't where the difference is: all 344 files decoded in about 6 ms total with gzip and 12 to 16 ms with Brotli.

What Cloudflare actually serves

This site is a static upload to Cloudflare Pages (the direct upload limits post covers that setup). I took the index page and 40 random articles and requested each one four times, changing only Accept-Encoding: identity, gzip, br and zstd. The uncompressed body matched the local file byte for byte on all 41, so I could compress the served bytes myself at every level and look for the setting that produced the size Cloudflare sent.

served gzip    402,828 bytes   local gzip -9  402,826   (exact size on 39/41 pages)
served br      398,455 bytes   local br q4    398,370   (nearest level on 41/41, within ±33 bytes)
local br q11   329,381 bytes   -18.2% vs what visitors got as gzip
Accept-Encoding: zstd          -> no Content-Encoding, 22,998 raw bytes (link-rot page)
Accept-Encoding: gzip, deflate, br, zstd -> br

The matching method is the dumb one: re-compress at each level and compare. In a 2022 Hacker News thread about a compression level estimator, compression library author klauspost put it this way: "You can compare the output from each level and that will be your guess, assuming of course that zlib was used in the first place." Brotli never matched exactly, only within 33 bytes, so Cloudflare is probably using a different window size or build than my Python binding. Every page still landed on q4 and no other level came close. There's no Content-Length on these responses and cf-cache-status reads DYNAMIC, which fits compression happening on the fly.

Quality 4 isn't a new choice. Cloudflare's 2015 Brotli experiment post concluded that "Brotli at quality level 4 is slightly faster than zlib at quality level 8 (and 9) while having comparable compression ratio." My numbers confirm the "comparable" part. On these pages, q4 and gzip -9 are within 1%.

The zstd line in the docs

Cloudflare's content compression page has a "Compression methods by plan" section that says: "Free Plan: Content is compressed by default using Zstandard." The API confirms picklog.cc is on the Free plan ("Free Website"), and the Brotli setting reads "on". Still, 0 of 41 zstd-only requests came back compressed. When a request listed zstd alongside br, Cloudflare picked br every time. The same page also says, a few paragraphs up, that customers "can enable Zstandard compression through Compression Rules." I've never created a Compression Rule, and my deploy token can't read that ruleset (it returns error 10000). So what I can say is: on a Free zone with no rules, Pages HTML comes back as Brotli or gzip, not zstd. I don't know which of the two doc sentences Cloudflare means as the rule.

That matters more for curl and scripts than for browsers, because a browser always offers br too. A client that sends only zstd gets the full 22,998 bytes instead of 8,203. How curl decides what to advertise is its own topic, covered in the curl --compressed post.

Why I'm not shipping q11

The fix people use is to precompress at build time and serve the .br file yourself. Pages won't do that for HTML on its own. Matt Hobbs wrote up how he does it: a Pages Function picks the file and returns it with encodeBody: "manual", which the Workers Response docs describe as the setting to use "when serving pre-compressed data to prevent automatic compression." For me it doesn't pay off, for two reasons:

• The saving is small in absolute terms. The median article goes from 8,910 bytes (gzip -9) to 7,305 (br q11). That's 1.6 KB per page view on a page that also loads a WebP cover image. Those covers are covered in the WebP quality post.
• It moves every HTML request off the free path. According to Pages Functions pricing, static asset requests are free and unlimited, but Function requests count toward the Workers Free plan's 100,000 per day. My click tracker already runs on that same account quota, and it has already hit a Workers KV daily limit once. Trading that headroom for 1.6 KB is a bad deal.

The build-time cost would be fine: about 6 seconds per full rebuild, a small addition to the upload step measured in the Pages deploy timing post. If this site served big JavaScript bundles or had real traffic, the math would flip. Brotli's 18% edge is real. It just depends on who's compressing and when.

Questions

Is Brotli better than gzip?

Only at high quality. On 344 real HTML pages, Brotli quality 11 was 18.0% smaller than gzip -9, but quality 4 was only 0.7% smaller, and qualities 0 and 1 were larger than gzip -1. CDNs that compress on the fly usually use a low quality, so most of the gain only shows up if you precompress at build time.

What Brotli level does Cloudflare use?

For dynamically compressed HTML on a Free-plan Pages site, the served bytes matched Brotli quality 4 on all 41 pages I tested, and gzip matched level 8 or 9. Cloudflare's 2015 Brotli write-up also pointed to quality 4 as comparable to zlib 8 and 9 in ratio.

Does Cloudflare serve zstd on the Free plan?

Cloudflare's docs say Free-plan content is compressed with Zstandard by default, and they also say zstd is enabled through Compression Rules. On a Free zone with no Compression Rules, 41 zstd-only requests came back uncompressed, and requests offering both zstd and br got Brotli.

Measured on 2026-09-18 between about 21:00 and 21:30 KST from an M4 Mac mini, using Python 3.14 with the standard gzip module, brotli 1.2.0 and zstandard 0.25.0. Sizes are totals of per-file compression, and times are sums of per-file best-of-5 (best-of-3 for Brotli 10 and 11 and zstd 15 and up). The live sample is the index plus 40 articles drawn with a fixed seed, fetched once per encoding over HTTPS with a browser user agent. Level matching compares each served size to local re-compression of the identical served body, so it names the nearest level, not Cloudflare's exact build settings. The plan name and Brotli setting come from the Cloudflare API. I could not read the Compression Rules ruleset, and the repository contains none. The Matt Hobbs setup and the HN quote are theirs, not something I ran.