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

Use zopfli and brotli for improved compression of assets #584

Closed
wants to merge 3 commits into from

Conversation

msand
Copy link

@msand msand commented Dec 31, 2016

I would recommend using zopfli for gzip/deflate compression and also to add support for and prefer brotli compression .

http://caniuse.com/#search=brotli

Currently supported in Chrome 50+ Firefox 44+ Opera 38+ Edge 15+ Android Browser 53+ Firefox Android 55+ Chrome Android 50+

@msand
Copy link
Author

msand commented Dec 31, 2016

Related to Issue #555

@rauchg
Copy link
Member

rauchg commented Dec 31, 2016

It'd significantly slow down build times correct? I'd like to make compression modular through the config, as we've discussed before.

@msand
Copy link
Author

msand commented Dec 31, 2016

True. Sorry, I didn't notice #243. That would enable optimizing for compression speed using brotli level 1, for compression ratio using level 11, for decompression speed with level 9, and for both faster and better compression than default gzip using level 4. Of course mileage may vary, and is data dependent, so benchmarking using some relevant data probably makes sense.

https://cran.r-project.org/web/packages/brotli/vignettes/brotli-2015-09-22.pdf
https://blogs.akamai.com/2016/02/understanding-brotlis-potential.html
https://blog.cloudflare.com/results-experimenting-brotli/
https://quixdb.github.io/squash-benchmark/

@rauchg
Copy link
Member

rauchg commented Dec 31, 2016

My understand of brotli / zopfli is that they make a very strict tradeoff: constant decompression speed, smaller build but much much slower compression. That's why the PR that maybe we need to aim for is the one that adds the optional compress fn in next.config.js

Would you agree?

@arunoda
Copy link
Contributor

arunoda commented Jan 1, 2017

I agree with @rauchg
gzip using zlib gives us decent compression and use don't need to install node binary build tools. (I guess)

Anyway, we should add support for customizing the compression via next.config.js. So, anything is possible.

@rauchg
Copy link
Member

rauchg commented Jan 1, 2017

Closing in favor of that approach

@rauchg rauchg closed this Jan 1, 2017
@msand
Copy link
Author

msand commented Jan 1, 2017

Yes, I would agree with @rauchg and @arunoda as well, Yes, zlib comes in Node.js core, so no build tools or even packages needed. Brotli is unlikely to arrive in core, in the short term at least.

An emscripten port of Brotli to js exists as well, and end-users optimizing for minimum payload size might be ready to sacrifice build/compression time for it... npmjs.com/brotli

Configuring native compression should be easy now, as binary build tools have become easy to install, On windows, that is, as that was the main user problem area. Thanks to https://github.com/felixrieseberg/windows-build-tools it's essentially just npm install --global windows-build-tools

So, support for custom config and zlib as default sounds great and probably keeps everyone happy 😄

@arunoda
Copy link
Contributor

arunoda commented Jan 4, 2017

@msand check this: #657

@lock lock bot locked as resolved and limited conversation to collaborators Jan 19, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants