5 ms·

The "nevermind brotli" seems overly dismissive. Browsers should add support for zstd, and I like zstd a lot, but I have found more cases than I would have expec

The "nevermind brotli" seems overly dismissive. Browsers should add support for zstd, and I like zstd a lot, but I have found more cases than I would have expected where brotli compresses files better than zstd, even while using a ridiculously high compression level setting on zstd (for example, 19). I can't remember encountering anything that compresses better with gzip than with brotli, so brotli is usually a better choice than gzip to reduce bandwidth, and brotli has been better than zstd on more than a few occasions for me as noted previously. Brotli is very worthwhile, at least for static assets, and choosing to offer only gzip compressed assets to browsers is almost always a waste of bandwidth. If faster to compress is all you care about, then sure, brotli might not be the best choice.

maximilianburke 4y ago
My views on brotli are just from my experience with it. I'm looking at my static assets now; our largest JS bundle is 6.3MB uncompressed. With brotli at level 9 it takes 400ms to compress down to 1.34mb, and with zstd at level 13 it squeezes down to 1.31mb in 300ms. If I use zstd at level 19, it takes 1.1s to compress, but size is even further reduced to 1.21mb. Decompression time is identical for both (33ms). So, for our static data the edge goes to zstd. For dynamic data there's no contest. Most of our responses are binary and brotli is not just slow, it's so slow we have to disable it otherwise people assume our services have hung. By far most of the data that leaves our servers is dynamic, so having zstd support in browsers would be a huge win for us because we would spend less time compressing (compared to gzip) and have smaller responses. I was looking at one particularly pathological case last month where we had a 2.7gb response that was quite sparse. We were spending 30s of server time as part of the request in gzip, the end result being 52mb. With zstd at level 12 it was 5s to compress it down to 41mb. I don't even know how long it would have taken with brotli as I stopped timing after 10 minutes. I mean, if brotli wasn't working for people it wouldn't be supported by browsers, but I really really wish zstd was an option.

maximilianburke 4y ago

My views on brotli are just from my experience with it. I'm looking at my static assets now; our largest JS bundle is 6.3MB uncompressed. With brotli at level 9 it takes 400ms to compress down to 1.34mb, and with zstd at level 13 it squeezes down to 1.31mb in 300ms. If I use zstd at level 19, it takes 1.1s to compress, but size is even further reduced to 1.21mb. Decompression time is identical for both (33ms). So, for our static data the edge goes to zstd. For dynamic data there's no contest. Most of our responses are binary and brotli is not just slow, it's so slow we have to disable it otherwise people assume our services have hung. By far most of the data that leaves our servers is dynamic, so having zstd support in browsers would be a huge win for us because we would spend less time compressing (compared to gzip) and have smaller responses. I was looking at one particularly pathological case last month where we had a 2.7gb response that was quite sparse. We were spending 30s of server time as part of the request in gzip, the end result being 52mb. With zstd at level 12 it was 5s to compress it down to 41mb. I don't even know how long it would have taken with brotli as I stopped timing after 10 minutes. I mean, if brotli wasn't working for people it wouldn't be supported by browsers, but I really really wish zstd was an option.