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

7.0.1 changes the brotli default quality #287

Closed
2 tasks done
fozcode opened this issue Mar 28, 2024 · 3 comments
Closed
2 tasks done

7.0.1 changes the brotli default quality #287

fozcode opened this issue Mar 28, 2024 · 3 comments

Comments

@fozcode
Copy link

fozcode commented Mar 28, 2024

Prerequisites

  • I have written a descriptive issue title
  • I have searched existing issues to ensure the issue has not already been raised

Issue

Hi, this is not an issue as such, just an observation and you can close it as you wish.

I had a test failure moving from 7.0.0 to 7.0.1 because for my use case of compressing text the brotli response went from being smaller than gzip to being larger. I'm not sure what the default quality was in 7.0.0 but apparently it wasn't 4.

7.0.0: plain text: 74081, gzip: 7736, br: 6716
7.0.1: plain text: 74081, gzip: 7736, br: 8436

I'm now explicitly setting the brotliOptions to get the better compression but I thought you might like to know that with the 'out of the box' defaults gzip is now giving better compression for some payloads.

@stanleyxu2005
Copy link
Contributor

stanleyxu2005 commented Mar 28, 2024

This is on purpose. From v7.0.1, the default brotli compression level is changed to 4 instead of 11.
It is documented here.

11 means maximal compression ratio but it is remarkably slow.
4 is a balanced value.

Sure you can explicitly set a best value for your own project.


It's a breaking change introduced in v7.0.0, so that you get a major version upgrade. Unfortunately, there is a bug to prevent the compress level change, so it is fixed now in v7.0.1.

@gurgunday
Copy link
Member

Thank you for the issue!

As explained by @stanleyxu2005, this change was supposed to be made in v7.0.0 but unfortunately did not work, so the patch release has simply fixed that bug

@fozcode
Copy link
Author

fozcode commented Mar 28, 2024

Thanks for clarifying! My bad for not going further back to see that this was the reason for v7. Appreciate the fast response.

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

No branches or pull requests

3 participants