According to some Firefox developers, brotli is more suitable because of the standardised dictionaries for web content, like JS: https://bugzilla.mozilla.org/show_bug.cgi?id=1301878
https://github.com/facebook/zstd#the-case-for-small-data-com...
zStd also supports pre-trained dictionaries, it is particularly good for specific small JSON, for example. It won't be that helpful for relatively large HTML files.
https://quixdb.github.io/squash-benchmark/unstable/?dataset=...
Perhaps, this common misunderstanding is due to the fact the slowest level (-11) is the default one in the brotli command line utility?
It's also faster than gzip, and gzip was used for "just in time" compression on the web for ages, so I don't see how brotli can be a problem for this use case. (I assume by "encrypt" you mean "compress".)
The thinking seems to be due to how CPU intensive it is, Brotil is not favoured for on-the-fly compression[2].
If you're really desperate for it though, you could try [this extension][3].
[1] https://caddyserver.com/docs/caddyfile/directives/file_serve...
Other webservers support it, mainly Nginx. But since Caddy is written in go, they need a native go port which doesn't exist yet.
Yeah, hence my "really desperate" qualifier. I probably should have been more explicit.