Ops Briefing: AMP HTML and Brotli
I’m not going to start with a reminder of how important app performance is. Let’s just all agree we already know this as the first app economy axiom and get on with the post payload. Actually, I know this is true because I’ve watched a staggering increase in the past year in use of web acceleration services including techniques like compression.
That’s why today’s ops briefing focuses on app performance and brings to your attention two emerging efforts (yes, both from Google, are you surprised?) designed to help you obey the first app economy axiom.
As for when you’ll start seeing AMP HTML pages on the web, they’re already out there, and according to the project blog, “Google will begin sending traffic to your AMP pages in Google Search early next year.”
The second effort comes from Google. Brotli is a new (okay, newish, introduced back in September 2015 but only now getting some interest) compression algorithm designed to replace Chrome’s current algorithm, Zopfli. Yes, they need to look at their naming process because neither sounds as cool as Lempel-Ziv. Google claims much better algorithmic performance using “2nd order context modeling, re-use of entropy codes, larger memory window of past data and joint distribution codes” and gains of “20–26% higher compression ratios over Zopfli.” The downside is that while Zopfli was deflate-compatible, Brotli is “a whole new data format.” Like HTTP/2 and its dramatic departure from previous implementations, that means web servers and intermediaries like proxies providing app acceleration capabilities would need to support it before it could be widely deployed.
As with other Google-driven efforts around web technologies, expect to see support first between Chrome and Google sites and apps.