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

Introduce brotli compression #174

Closed
mingard opened this issue May 30, 2017 · 6 comments
Closed

Introduce brotli compression #174

mingard opened this issue May 30, 2017 · 6 comments

Comments

@mingard
Copy link
Contributor

mingard commented May 30, 2017

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.

@jimlambie
Copy link
Contributor

We'd need to add this as an alternative, rather than a replacement, right? Based on whatever the browser sends in the accept header?

@jimlambie
Copy link
Contributor

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)

@mingard
Copy link
Contributor Author

mingard commented May 30, 2017

We'd need to add this as an alternative, rather than a replacement, right? Based on whatever the browser sends in the accept header?

Yes, it'd be an alternative.

unless we key the cached item with it's compression type

Yes, that's an interesting obstacle. Caching with a key seems like an elegant solution.

@abovedave
Copy link
Contributor

abovedave commented May 30, 2017

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 config.headers.useGzipCompression and adding config.headers.useCompression in there to cover this change.

That issue suggests we should compress before caching, as the compression is an expensive operation.

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.

@mingard
Copy link
Contributor Author

mingard commented May 30, 2017

config.headers.useCompression 👍

I have some ideas for page pre-compression. I'll try and summarise in a concept issue

@abovedave
Copy link
Contributor

abovedave commented May 30, 2017

Nice @mingard: if you can think about assets too that can feed into CDN methodology 🌮

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

No branches or pull requests

4 participants