We perform SDCH and Brotli on the reverse proxy that's in front of our "front-end" origins. Since some clients at that level need to be able to perform transfor

We perform SDCH and Brotli on the reverse proxy that's in front of our "front-end" origins. Since some clients at that level need to be able to perform transformations they can only perform on either non-encoded or gzip-encoded responses, we can't have Brotli happen before then. At that point we can either take the cost of inflating the gzipped response and then doing Brotli or just sending it away gzipped. That's why we have a higher threshold for the benefits we would need to get from Brotli before using it more broadly. We are compressing our SDCH dictionaries with "br" as well. Brotli is great for static content if you know that the user agent that would frequently request that resource supports it. We also have our internal "massively" multi-threaded dictionary generator that we will want to open-source with our plugin. And we have indeed experimented with all those combinations. Here are some results: Using the dictionary generated on <Some popular page>: Dictionary generation parameters: [128 iterations per pair] [12 threads] sdch+brotli vs. identity 92.9072% sdch+gzip vs. identity 92.7303% brotli vs. identity 80.0409% sdch+brotli vs. gzip 72.0629% sdch+gzip vs. gzip 71.3661% sdch+brotli vs. brotli 64.4635% brotli vs. gzip 21.3848% sdch+brotli vs. sdch+gzip 2.43356% Using the dictionary generated on <Some popular page>: Dictionary generation parameters: [1024 iterations per pair] <-- more [12 threads] iter sdch+brotli vs. identity 94.2345% sdch+gzip vs. identity 94.2343% brotli vs. identity 80.0487% sdch+brotli vs. gzip 77.2907% sdch+gzip vs. gzip 77.2898% sdch+brotli vs. brotli 71.1021% brotli vs. gzip 21.4154% sdch+brotli vs. sdch+gzip 0.00399263% <----- High iteration SDCH dictionary generation eats Brotli's lunch.