Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for brotli #21

Closed
christophehurpeau opened this issue Mar 30, 2016 · 15 comments
Closed

Support for brotli #21

christophehurpeau opened this issue Mar 30, 2016 · 15 comments

Comments

@christophehurpeau
Copy link

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

@christophehurpeau
Copy link
Author

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

@jonathanong
Copy link
Member

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

@haoxins
Copy link
Member

haoxins commented Mar 31, 2016

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

@eknkc
Copy link

eknkc commented May 9, 2016

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

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

@ShimShamSam
Copy link

Any progress on this?

@jonathanong
Copy link
Member

PR welcomed :)

@dlebedynskyi
Copy link

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

@jonathanong jonathanong self-assigned this Apr 6, 2018
@jonathanong
Copy link
Member

jonathanong commented Apr 14, 2018

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
Copy link

dlebedynskyi commented Apr 16, 2018

@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
Copy link
Member

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

@tracker1
Copy link

tracker1 commented Aug 13, 2018

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

@syuilo
Copy link

syuilo commented Feb 3, 2019

Note: Node.js now supports Brotli natively.

@dennismphil
Copy link

Any progress on this?

@indeyets
Copy link

@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
Copy link
Member

closed by #99

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants