Support

There is a reason why this is not supported for NginX. Actually two reasons, closely related.

On Apache we can use a combination of HTTP header detection, environment variable setting, and conditional redirection to have the server serve a precompressed file when the client claims to support the relevant encoding.

In NginX this trick is not possible. You would need the ngx_http_gzip_static_module module which does ship with the mainline NginX source distribution, but it has to be explicitly enabled with the --with-http_gzip_static_module compile-time option. Since this is rarely the case with commercial hosts and because referencing the gzip_static and gzip_vary it provides when is not installed would result in the server not starting I chose not to implement it at all. But more on that later.

Brotli support has been removed from Joomla's htaccess.txt because they couldn't make it work without double-encoding; they decided it's best removed than risk it cause problems. I made it work in Apache, but it was a freaking chore and a half as you can grasp by the complexity of the generated code.

On NginX there is nothing similar to ngx_http_gzip_static_module for Brotli.

That said, all of that is absolutely pointless. Any server CPU released the last 15 years is more than capable enough to Gzip-compress static CSS and JS on the fly. The difference I measured between statically compressed files and dynamically compressed files when hammering a very feeble server with requests was below measurement error. The only real world use case where pre-compressing static media makes sense is large scale deployments which are NOT something you'd be using Joomla for.

Brotli takes a bit longer, making the measured difference between dynamic and static compression be around 10 msec (0.01 seconds) under the same test, just above the measurement error threshold of 8 msec, giving a very low confidence that there is a meaningful difference. Even worse, the difference in size between Gzip and Brotli compressed files shipped with Joomla was under 5% which made zero practical difference: a single slightly unoptimized image would have a much larger effect.

To top it all up, if you have a busy site which would benefit from a single digit millisecond performance differences in page load you'd very likely be using a caching CDN like CloudFlare to serve your site. Guess what? They can compress those files for you and keep those compressed files cached on their side, completely nullifying the need for you to deal with that on your side.

Which is to say: if you have a slow site the pre-compressed CSS and JS files will have absolutely no practical impact whatsoever. Most of your performance issues are in loading a tonne of unnecessary CSS and JS, unoptimized images, and your server itself. Trying to fix that with NginX / Apache tricks is not going to help you any. You will spend a lot of time for marginal gains that have zero observable performance impact. If anything, time-to-first-byte, FCP and LCP will have a far more pronounced impact on how your users perceive your site's speed.