Simple: Brotli was initially shipped as a part of WOFF2 compressed font file format, and its creators foresaw more possible uses in the web browser, tailoring its built-in preset dictionary for web contents. It is no doubt that Zstandard is faster than Brotli, but both are sufficiently fast enough for web contents (100 MB/s and more), so an additional gain from Zstandard was much smaller. Given this, I believe Zstandard support in web browsers was possible only due to the strong push from Meta.

> For the rest of us, another half-decade+ wait to get useful levels of compatibility especially on mobile

Chrome already ships it with their currently released browsers, so you get a significant amount of mobile traffic (about 42%) from Android devices supporting it already. I don't know what the current status of Blink on iOS is, but once that releases, you'll also get iOS users.

WebKit has reacted positively to the proposal, though the Github issue documenting their position refers to an internal radar ticket so I have no idea what their timeline is.

If you build for Chrome today, compatibility will only grow. Chrome doesn't do compression levels above a certain point but I doubt Safari and Firefox will be affected by a different limitation when support eventually lands.

Plus, if your web server is configured well, you can have the gzip/brotli/zstd content available right next to each other, and just follow the browser's preference to pick a supported compressed asset.

There really are no downsides here.

If you “build for chrome today” you create a chrome only monopoly exactly as web devs did with IE.

Or you could build your site properly and have it work on more than a single browser.

You do you.

Other browsers will implement the feature soon. This isn't like webgpu or webusb, which just appeared before other browsers even reacted.

If Firefox and Webkit do introduce compatibility issues, you can always correct those later, though I doubt there will be any.

the web still works without content encoding, so you optimize for the common case but it still works for everyone

Because of HTTP content negotiation, you can serve zstd to Chrome users today, so “useful levels of compatibility” doesn’t make sense in this context.

Try saying it out loud with 1 TB to recompress and host for a fraction of users to save some CPU, because if we're talking CPU we're talking latency, and there's not much point in changing if you're running zstd --ultra --long -22 for every request