Support for brotli

[christophehurpeau]

Here an interesting link : https://hacks.mozilla.org/2015/11/better-than-gzip-compression-with-brotli/

[christophehurpeau]

I could try to make a PR if you're interested

[jonathanong]

imo we should just have an api for adding more compression methods

[haoxins]

Looks like expressjs/compression#62 ?
This issue is duplicated with #19 ?

[eknkc]

BTW, Chrome seems to have brotli enabled by default for upcoming versions:

https://chromium.googlesource.com/chromium/src/+/e3118678848807c0ea60ab086e3d803cb1913098%5E%21/#F0

[ShimShamSam]

Any progress on this?

[jonathanong]

PR welcomed :)

[dlebedynskyi]

Hey, guys, wondering if there is any progress on this? would love to see brotli support added

[jonathanong]

was going to implement this but it seems as though brotli is only better on larger sized payloads. we might need to think about how we implement this more. my 2048-byte test buffer actually got bigger with brotli somehow.

[dlebedynskyi]

@jonathanong followup on that - did some testing myself recently using https://github.com/tuananh/kompression and https://www.npmjs.com/package/shrink-ray

• compression time seems bigger then gzip (level 9) for around same dynamic content size of ~15kb
• brotli does help with static files though roughly 5-10% save on brotli for static files around ~100kb gzip

also noticed that brotli indeed uses more memory.
we ended up using brotli for static and gzip for dynamic content.

I can try help with PR if you need but not sure if it is worth it at all.

[jonathanong]

yeah i'm not sure it's worth it. seems like it's better to let your CDN do the extra heavy lifting.

[tracker1]

Added a PR #80 which implements optional brotli support... I would specify a quality of 5-8 though instead of the default of 11, as it will be much slower than gzip otherwise. You really don't gain much for dynamic content vs. the extra time for compression. I did the work and made it optional in case someone really wants it, or in case the iltorb library gets significantly better.

my single use case (JSON response, 181k uncompressed):

encoding  level/quality  time   size
gzip      9              36ms   129kb
br        11             441ms  127kb
br        8              43ms   128kb
br        6              38ms   128kb
br        5              36ms   128kb