AMP & Standards

Paul Bakaus
Jun 27, 2016 · 2 min read

When describing AMP as a stop gap measure, I really liken AMP to being a fast, effective remedy for a web that was very sick. We are trying to stop the blood from flowing, so the surgeons can deliver long term health to the patient. In the case of AMP, the surgeons are emerging web standards.

The AMP team (myself included) chose to implement AMP as a open source library to be able to iterate and test grounds quickly to see what sticks — in line with the extensible web manifesto. But we’d absolutely love to see a future where the important bits of AMP are standardized by the W3C and are willing to work with anyone who wants to help.

I’ve been on the jQuery team for many years, and personally have seen how a library can drive meaningful, healthy change to the ecosystem at large. This is what we want.

The important bits that need some form of standardization, in no particular order:

  1. A easy-to-test guarantee that a page is fast and user friendly (with AMP, all you do is scan the markup and run a quick validation, very little effort and cost involved. Try reliably testing another web site for run time and load time perf..)
  2. A static layout system that allows the prerender/preload of the visible viewport (this means no external assets that could cause reflow)
  3. A guarantee that the current page is self-contained, and contains/links to all resources required to display the content (this allows AMP viewers to proxy/cache AMP docs for maximum performance without worrying that they’re missing some external dependencies)
  4. A way to lazy load (or only load when visible) external assets, especially images. There’s a recent attempt at this, but the thread is stalling. Please help if you can.

Out of all of these, number one is the hardest. You can get there half way through self restraint (we’ve started to work on this), but it’s not enough. Just a few lines of JS are enough to kill a page’s performance (which is why user authored JS is a no-go on AMP pages). Malte has written about a possible path going forward with the help of web workers to effectively throttle JS and DOM updates.

Paul Bakaus

Written by

Open Web Developer Advocate at Google • Tools, Performance, Animation, UX • HFR enthusiast • Creator of jQuery UI and the first HTML5 game engine (Aves Engine)