Please compress static content with brotli level 11

Even static files often change. .css .png .svg and if served as static, the .html will change more often than the aforementioned file types, generally speaking.

Here we are talking about css/js files, that won’t change at each request and there is no need to dynamically compress them. It can be done once for all. What i mean with this is that as part of your build pipe (with webpack, gulp, of whatever else you are using) we are also compressing the file and generating a .css.br and .js.br file that will be stored as a file and delivered as it is with no additional compressing time while served, since it’s already compressed. (of course compression take time at “build” time). Then of course file will change in the future, with future build, and we will compress them again when we create the new build.

I’m totally not talking about HTML here which will of course change for every user and I’m already fine with what cloudflare does by default.

Also as already mentioned, the decompression time does not increase that much increasing the compression level.

https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html

This seems to be the “fairest” comparison using various levels of each algo.

Also, since the files will be compressed on your end before being sent out, check out these other algos which I randomly happened to find:

      `compression ratio : decompress speed`

iPadPro64 : kraken : 3.678 to 1 : 762.104 MB/s

iPadPro64 : kraken444 : 3.551 to 1 : 739.046 MB/s

iPadPro64 : mermaid : 2.875 to 1 : 1696.071 MB/s

iPadPro64 : selkie : 2.379 to 1 : 2974.148 MB/s

iPadPro64 : zlib9 : 2.890 to 1 : 306.462 MB/s

iPadPro64 : brotli9 : 3.254 to 1 : 170.085 MB/s

iPadPro64 : brotli11 : 3.534 to 1 : 155.434 MB/s

Full info is here: https://www.cbloom.com/oodle_arm_report/
However, I’m unsure of the license terms for all but zlib & Brotli, as they are proprietary (for now). Though it may be at the very least interesting to look into if serving to mobile clients - Android, iOS, iPadOS, & Windows. Adding a second Content-Encoding header via workers might possibly enable the use of / advertisement of the additional compression algos.

Also of interest: https://www.opencpu.org/posts/brotli-benchmarks/

[Apparently Brotli’s use value plateaus at 9.]

Also of interest as it’s open source :

I’m a research junkie; parts of these sites are / may be irrelevant to your exact request for Brotli 11; however data is data and is worth the time to see the numbers.

:slight_smile:

1 Like