koajs/compress

Support for brotli

christophehurpeau opened this issue · 15 comments

christophehurpeau commented

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

  • 👍6
jonathanong commented

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

haoxins commented

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

eknkc commented

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

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

  • 👍3
ShimShamSam commented

Any progress on this?

jonathanong commented

PR welcomed :)

dlebedynskyi commented

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

jonathanong commented

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 commented

@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 commented

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

tracker1 commented

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
dennismphil commented

Any progress on this?

indeyets commented

@jonathanong brotli makes a lot of sense for API responses under high load. we usually sticked to gzip -1 (lowest possible load), but brotli -3 uses even less cpu resources while providing better compression (even for small files)

CDN doesn't help with API :-/

jonathanong commented

closed by #99