Contact emails
Engineering:
eus...@chromium.org (chromium integration)
{jyrki@, szabadka@, lode@}google.com (Brotli)
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.
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.
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.”
Note: we are considering restricting to/starting with HTTPS only so we can avoid adding yet another batch of workarounds/special casing.
We actually have an internal product that does recompression for images which we can adapt to recompress text so that we can make Brotli available. We would not do on-the-fly recompression because the compression speed just isn't there and at our scale would not make sense. We can look at Brotli compression of static text assets that are in our cache.
If this becomes a reality we are likely to support it by making this transparent for our customers. We try to stay on top of new technologies like this and offer them freely.
Note: we are also interested in other compression algorithms. For example, lzma. If browsers start offering Accept-Encoding: gzip, deflate, brotli, sdch, lzma etc. then we will look at supporting.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Brotli being considerably faster for decompression than LZMA is indeed one reason.
The other reason is that we originally considered LZMA for Woff 2.0 but had to give up because of the lack of a proper specification and willingness to create one. We reached out internally for an alternative. The compression team at Google offered to help and delivered beyond our expectations :)
--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CADWWn7V3gOR_Y36vwtOh_nJpxRtUGsk8cT9oVj2gL%2BYmHHRCTg%40mail.gmail.com.
This intent to implement is about making Brotli available as a content-encoding method (e.g. Accept-Encoding: Brotli)
Yes, we wanted something shorter and are settling down on br for A-E and the file extension.
--
You received this message because you are subscribed to a topic in the Google Groups "net-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/net-dev/xdVm8c2GOMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CADWWn7XaHFrtFsid3f%2B4CtaETZusGdbJ3iGpwveUirM8AiOeWA%40mail.gmail.com.