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.
AMP HTML
The first one, AMP (Accelerated Mobile Pages) HTML, is an experiment targeting mobile apps (which is a big deal these days, in case you missed that) but that does not exclude traditional (fatter) clients. AMP HTML seeks to put constraints on content – refusing current ad and third-party content inclusion techniques (via JavaScript, primarily) and instead leveraging core HTML elements to achieve the same goals.
From the author’s description: “we made the tough decision that AMP HTML documents would not include any author-written JavaScript, nor any third-party scripts.”
Getting around this can be difficult. Web developers have long relied on JavaScript to modify, integrate, and provide the interactivity expected by today’s consumers. The project seeks to replace JavaScript functionality with existing or custom HTML elements, such as iFrames, that can effectively recreate most effects without negatively impacting performance. CSS is not similarly restricted, which should go a long way toward enabling the responsive web apps we’ve all come to expect.
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.”
BROTLI
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.
Stay fast!
