Brotli compression significantly slower than gzip

[revbingo]

I have enabled the automatic compression on responses, and have an endpoint that generates a various sized responses from a lambda running with 2048Mb of memory. Chrome's default Accept-Encoding header of gzip,deflate,br causes Brotli compression to be used as the priority, but this is consistently noticeably slower than when gzip is forced.

The table below shows compressed sizes and response times (including network round-trip, and measured unscientifically but consistently) for various responses. I've omitted deflate as it's virtually the same performance profile as gzip. As you can see, in all cases Brotli is significantly worse than not compressing at all. In the worst case - which is actually closest to my production profile - Brotli adds over 15 seconds to the response time.

Uncompressed	Gzip	Brotli
100kb - 1.5s	10kb - 1.3s	7.5kb - 1.6s
1Mb - 4.6s	70kb - 4.1s	49kb - 7s
2.5Mb - 6s	150kb - 5s	100kb - 13s
5Mb - 7s	260kb - 5.5s	170kb - 22s

It seems perhaps the Brotli compression ratio is set too aggressively by default?

[jeremydaly]

Thanks, @revbingo. I’ll take a look. @AndrewBarba, any thoughts on this?

[AndrewBarba]

My understanding is Brotli is much more CPU intensive than gzip. It does provide better compression (as noted in your table) but perhaps it should not be enabled from the Node process and is much more suited to be done at the edge in a more optimized runtime.

I definitely should have done more testing on this before making Brotli the priority. My recommendation would be to only include gzip and deflate when compression: true and perhaps support an additional form like compression: ['brotli', 'gzip'] so its opt in.

Let me know what you think and I'll get a PR together

[AndrewBarba]

@jeremydaly @revbingo PR here https://github.com/jeremydaly/lambda-api/pull/190

[revbingo]

Thanks for the quick work @AndrewBarba !