Kenji Baheux
Intent to Implement: support for Accept-encoding: Brotli
Contact emails
Engineering:
eus...@chromium.org (chromium integration)
{jyrki@, szabadka@, lode@}google.com (Brotli)
PM:
Spec
https://tools.ietf.org/html/draft-alakuijala-brotli-04
Summary
Brotli is used in WOFF 2.0 web fonts with great success.
This intent to implement is about making Brotli available as a content-encoding method (e.g. Accept-Encoding: Brotli).
Advantages of Brotli over gzip:
- significantly better compression density (6.7x on fetch logs)
- comparable decompression speed
Disadvantage of Brotli over gzip:
- slower compression speed making it less useful for serving dynamic assets*
*: different compression settings can be used to strike the right balance between compression density and compression speed.
Motivation
Beyond its proven track record on web fonts, Brotli also leads to significant gains on other critical web assets (e.g. JS, CSS or document fragments). Brotli should improve page loading time.
In addition, given that JS and CSS assets tend to be block rendering, we expect that Brotli will also have a positive impact on RAIL metrics such as time to first meaningful paint.
Finally, transferring less bytes will also benefits users who are on a prepaid plan or have a bandwidth cap.
Compatibility Risk
Internet Explorer: No public signals
Safari: No public signals
Firefox: Positive signals
In particular, this comment by Patrick McManus seems relevant:
“I continue to be open to the prospect of adding a non-deflate based decoder and the negotiation for it as part of Accept-Encoding. I've said upthread a few times that what we need is a content provider willing to do make a real use case available for negotiation that way - then we can see how it works out.”
Web developers: Positive signals
For instance, Ben Maurer commented:
“Doing some ad-hoc tests on the Javascript and CSS at Facebook we see some substantial improvements. Brotli would save about 17% of CSS bytes and 20% of javascript bytes (compared with zopfli). Resource download times are a big bottleneck, so this would make a big impact for page load times.”
Going back to Patrick’s comment about the need for a dance partner, it sounds like Facebook is interested and we have internal customers interested as well.
Describe the degree of compatibility risk you believe this change poses: Low compatibility risk.
The content-encoding scheme is negotiated between UA and Servers via the Accept-encoding HTTP header.
Ongoing technical constraints
None.
Note: we are considering restricting to/starting with HTTPS only so we can avoid adding yet another batch of workarounds/special casing.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux,
Chrome OS, Android, and Android WebView)? Yes.
OWP launch tracking bug
http://crbug.com/452335
Link to entry on the Chromium Dashboard
https://www.chromestatus.com/features/5420797577396224
Requesting approval to ship?
Not just yet as we need to clear a few questions before hand.
