-
Notifications
You must be signed in to change notification settings - Fork 16
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
Introduce brotli compression #174
Comments
We'd need to add this as an alternative, rather than a replacement, right? Based on whatever the browser sends in the accept header? |
We also need to think about how this would work with it: #158 That issue suggests we should compress before caching, as the compression is an expensive operation. If we have two types of compression possible, we can't really store the compressed response (unless we key the cached item with it's compression type) |
Yes, it'd be an alternative.
Yes, that's an interesting obstacle. Caching with a key seems like an elegant solution. |
I've implemented br already in #167 for assets, so happy to add it to the page response too in that PR 👍 I'm also floating the idea of deprecating
That's an interesting idea of pre-compression, which nobody is really doing. Would be nice with assets also - although that sounds like something to roadmap as it's more complex? We have our cache headers in order so this only affects first response. |
I have some ideas for page pre-compression. I'll try and summarise in a concept issue |
Nice @mingard: if you can think about assets too that can feed into CDN methodology 🌮 |
Brotli is an alternative compression that provides, in real world testing, around 20% smaller payload than gzip.
useful package: https://www.npmjs.com/package/brotli
useful resources:
https://css-tricks.com/brotli-static-compression/
https://engineering.linkedin.com/blog/2017/05/boosting-site-speed-using-brotli-compression
https://hacks.mozilla.org/2015/11/better-than-gzip-compression-with-brotli/
Also applicable to CDN.
A potentially significant performance increase with a minor technical overhead.
Thoughts please.
The text was updated successfully, but these errors were encountered: