Poor Brotli compression performance with the Node defaults

[naggingant]

What is your Scenario?

I noticed non-negligible performance degradation when Hammerhead proxies contents compressed with Brotli

What is the Current behavior?

Chrome-based browsers, for example, accept Brotli compressed content by default on HTTPS or localhost connections (feature).
In our case, this resulted in severely low performances (mostly 5-10x slower depending on the file size) when running TestCafe with --hostname localhost option or SSL enabled and connecting to servers that support Brotli, compared to when compressing in Gzip, especially when the file is around/more than a megabyte.

What is the Expected behavior?

The poor performance is likely due to the default compression quality defined in the wrapped library, which is set to the maximum 11 (permalink, also note that it varies from 0 to 11) after some experimenting with lower quality settings like 4-7
It's been discussed in several performance-sensitive projects that depend on it, such as in dotnet/runtime#26097, koajs/compress#121

I don't think there is an absolute solution and I understand that it is often best to follow the dependency defaults, but I'm filing this in hopes of better future user experiences for I believe users would naturally expect similar performance characteristics between the compression algorithms, and this one was a bit hard for me to debug. So hopefully, a more "balanced" default or a way to control the compression level, or just an open discussion would be very much appreciated.

What is your public website URL? (or attach your complete example)

It requires a server that supports both Gzip and Brotli, and respects the Accept-Encoding HTTP header, in order to reproduce the issue. I found Cloudflare CDN met this.

Also, since the characteristics are more significant with large files, typically +1MB, I picked these for demonstration, though the low performance can be seen with smaller files (or any other types of files the server chooses to encode):

• https://cdnjs.cloudflare.com/ajax/libs/typescript/4.5.5/typescript.js (9.5MB)
• https://cdnjs.cloudflare.com/ajax/libs/typescript/4.5.5/typescript.min.js (3.0MB)
• https://cdnjs.cloudflare.com/ajax/libs/angular/12.2.16/core.umd.js (1.47MB)

What is your TestCafe test code?

No TestCafe code needed to reproduce, but I can provide one if necessary

Your complete configuration file

No response

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

1. Start playground: node node_modules/gulp/bin/gulp http-playground
2. Download a file with gzip compression

   $ curl -sLo /dev/null http://localhost:1400 \
       -d url=https://cdnjs.cloudflare.com/ajax/libs/typescript/4.5.5/typescript.min.js \
       -w TTFB: '%{time_starttransfer}s' \
       -H 'accept-encoding: gzip'
   TTFB: 0.583055s

3. Download the file again with br compression and compare the time to first byte

   $ curl ... \
       -H 'accept-encoding: br'
   TTFB: 5.202707s

TestCafe version

v1.18.3 (testcafe-hammerhead v24.5.13)

Node.js version

v14.19.0

Command-line arguments

testcafe chromium --hostname localhost tests/

Browser name(s) and version(s)

Chromium 97

Platform(s) and version(s)

Linux 5.16.4-arch1-1

Other

Seemingly the same issue has been reported several times in the past:

• Performance Issues with Brotli Compression testcafe#5670
• 30s delay on .js asset request using testcafe proxy with localhost and origin hosted behind Cloudflare proxy (cache disabled) testcafe#6385

I could not attach any benchmark report, but I can give it a try if required.

Thank you.

[miherlosev]

Hi @naggingant

Thank you for pointing this out. We will investigate this case and consider changing the default compression level.