We apologize for the instability of composr.app and appreciate your patience. We are working on the statistics addon and trying to find an optimal way to store and render data. Unfortunately, we have yet to find a solution that can handle the traffic (and therefore, tens of millions of statistical records) of composr.app. We're working hard on one.
Interesting/relevant note - Brotli is HTTPS-only. This is because they figure proxies will cache Brotli content served under HTTP and cause all kinds of bugs for UAs not supporting it.
Also see https://github.com/kjdev/php-ext-zstd
EDIT: While zstd (aka zstandard) is gaining adoption, and is by a web company, it is not itself designed as an HTTP compression scheme, and nobody is picking it up as such.
This is now implemented. It does not depend on Apache or PHP supporting Brotli, as I've taken a different approach. The old gzip option is now an output compression option, and you can select to output Brotli (which falls back to gzip if needed). If there's no PHP support for Brotli it will encode via shell_exec to the brotli executable (EDIT: but not for the main HTML output, as you cannot set an output_filter to a user-defined function or set one at run-time, and output buffers are not appropriate for implementing compression as they may process multiple times).
"Javascript files compressed with Brotli are 14% smaller than gzip. HTML files are 21% smaller than gzip. CSS files are 17% smaller than gzip."
There is a PHP extension we can support:
https://github.com/kjdev/php-ext-brotli
We can also try our .htaccess trick of serving pre-heavily-compressed .br files directly if the browser accepts them, like we currently do with .gz.
EDIT: While zstd (aka zstandard) is gaining adoption, and is by a web company, it is not itself designed as an HTTP compression scheme, and nobody is picking it up as such.