Brotli compression is very slow

Brotli seems to be extremely slow to compress files, the Umbraco backoffice JS bundle takes a whole 10 seconds to be served when using Brotli. After I overwrote the RequestHelper to instead use gzip when available the time fell to 1-2 seconds.

I realize though that Brotli seems to do a better job at compressing the file (~400 KB vs ~600 KB for gzip), however, 10 seconds seems an unreasonably long time to compress the file, so I’m thinking it could perhaps be a bug somewhere?

I’m guessing at the end of the day it might not be a huge problem if the file is aggressively cached when running in production, but it still seems like something is off to me.

[Shazwazza]

Sounds reasonable. But I wonder based on what @nikolajlauridsen says, if these would need to be configurable per bundle? Just like the cache buster is configurable per bundle. i.e. Global and Bundle level like many of the other options.

We need to find out what the ‘ideal’ level for brotli is and make that the default. I’m unsure if ‘lowest’ is the best. IMO the ‘best’ will be the setting that is faster and smaller than gzip.

[PhyxionNL]

Brotli is slow to compress at higher levels, while decompression is faster. Some benchmarks are here: https://quixdb.github.io/squash-benchmark/#results-table E: site seems bugged. Here’s an alternative benchmark; https://community.centminmod.com/data/attachment-files/2019/04/7885_compress-benchmarks-010.png

But these files will be cached on disk (unless you use Smidge.InMemory), so it shouldn’t matter too much. It’s just a one time thing that happens.