Brotli compression in addition to gzip
attisan opened this issue · comments
Brotli provides significantly smaller payload sizes and thus would / could further improve response speed. Could be integrated optionally in case https://github.com/kjdev/php-ext-brotli is detected?
Sounds like a good addition, so you want to provide a small PR?
I'm on it. Should I Add it to CompressionMiddleware or stack a new BrotliCompressionMiddleware in in case Brotli is available? Doing the latter would keep the CompressionMiddleware a bit more readable as we need to use brotli_compress_init instead of deflate_init (and friends).
I think it makes sense to roll support into CompressionMiddleware. You'll probably want to split out deflate and brotli into separate handler methods and defer to them to keep it clean and readable.
Will do that - just a small side note: compared to gzip, brotli does take a considerable amount of overhead (ballpark of 50-100ms). I have achieved best performance with disabling amphp http-server compression (completely) and reverse proxying through nginx with enabled compression.
Imo: having brotli available in the amphp http-server still has its validity though, as letting nginx handle the compression does outperform amphp http-server with either compressions algorithms.
Yes, it's certainly nice to have available. I wonder though if in v3 we should default to compression being disabled? Probably doesn't matter too much, as named args make disabling compression trivial (i.e., new SocketHttpServer($logger, enableCompression: false))
should there be a setting indicating if Brotli should be used? I'm undecided on whether Brotli should outweigh gzip if it is available on the server as it does slow down the response.
I wouldn't prefer Brotli by default if it has significant overhead.