by Matt Brennan

You Don't Get AMP

I’m at AMPConf in NYC, and yesterday’s panel, “AMP & The Web Platform” raised some interesting questions around AMP’s place within the web ecosystem. Watch the recording, it’s fastastic stuff, and Tim Kaldec has a great summary of the concerns raised about AMP.

But the framing of some of the questions, both in the panel and the Q&A later that afternoon, highlighted to me that some people are looking at AMP from entirely the wrong angle. I think taking a step back and looking again might help reconcile how Google and the developer community are approaching AMP.

The Many Faces of AMP

When people talk about AMP, they’re talking about one of several things, and if somebody’s feelings about AMP are surprising it’s probably because they’re not thinking about the same “AMP” you are.

AMP the HTML format

The AMP that most people mean is the restricted HTML format, as laid out by the AMP Spec, and verified by the AMP Validator. Along with this is the AMP Runtime, the collection of custom elements– amp-img, amp-carousel, amp-ad and so on– that replace their HTML equivalents with something whose performance is both predictable and verifiable.

And yes, it’s true that you can write a site that is fast by avoiding a lot of what HTML can do. Turns out that not doing anything is a pretty good way of running fast. But the purpose of AMP HTML isn’t just being fast, it’s being verifiably fast. It’s being able to look at the markup of a page– just the markup, not even loading the page once– and go “yup, that’s fast”.

AMP the Google Search carrot

The Search team will try to weasel out of this claim, but AMP results do get prefrential treatment. It’s almost impossible for something to rank above the Top Stories carousel, unless you’re searching for something like “facebook”, which, yeah, the top result is going to be facebook.com.

This is the aspect of AMP I’m by far least comfortable with, but Google gonna Google. They’ve been dangling carrots in front of publishers for twenty-one years. And the now-ubiquitous ⚡️ has pretty good user recognition. It’s a pledge: “This site is fast; in fact, it’s instant. This site won’t jump around under your thumb. This site doesn’t have obtrusive ads. This site won’t try any shenanigans like redirecting you to the App Store page for Clash of Clans”.

You can’t make those promises with 100% bulletproof statically verifiable certainty without AMP.

AMP the (Google) CDN

When Googlebot finds an AMP page, it gets handed off to the AMP CDN, which AMP-validates the page, and stores it if it’s valid. Google Search results pages look in the CDN and AMP pages get the ⚡️.

Sites can and do run their own CDNs. It’s a performance best practice, and I’m guessing that if you’re big enough to start thinking about AMP you probably already have a CDN. The key is it’s Google’s CDN, and they can trust it.

And anybody can write an AMP Cache; Cloudflare have done just that, and I’m sure we’ll see more high-profile companies getting on the AMP train. In fact, the AMP Project have a set of fairly strict guidelines on what constitutes a Good AMP Cache™. But these are just guidelines, and Google can’t guarantee they’re behaving well, so they’re not first-class citizens.

I’d love for this to be something you could statically verify, just like AMP HTML, so that anybody could add a Cache to the ecosystem and get a lightning bolt on Google search results and Cloudflare links and Twitter Moments™, but I’m pretty sure this reduces to the Halting Problem.

None of these are AMP. All of these is AMP.

When talking about AMP, it’s disingeneous to look at one aspect and assess its merits in isolation. Each one of the pieces has tradeoffs, isn’t doing what publishers haven’t been doing for the last fifteen years, can be done by anyone, whatever. AMP is the whole thing working together.

The Secret Sauce of AMP

One of the questions posed in the panel by Jeremy Keith was “What is the secret sauce of AMP? Is it the cache or is it the custom elements?”. The short answer is “yes”. The long answer is “and then some”.

AMP is fast because it’s prerendered

Tap a Top Stories card, and bam, you’re in the article. Takes maybe 100 milliseconds, just at the edge of perception. You can’t do that with a full page load: not on a 3G network, not on a mobile CPU.

To get this kind of performance, the page must be prerendered. There actually is some support in HTML for this, in the form of Resource Hints. Add <link rel="prerender"> to the head and you’re done.

But since it’s rendering the page as if the user had actually clicked on it, scripts run, images load, everything runs in the background, so you need to be pretty conservative in what you prerender. And you have no control over what gets rendered and when; it’s all or nothing, and you can’t stop it. So you’d probably rather not prerender ten entire Top Stories results all at once. Plus, the browser support isn’t there yet; no Safari means no iPhones means ignoring 20% of your traffic.

So to implement prerendering, Google loads the AMP results within the page. It needs to be able to trust the content, so it needs to be able to trust the CDN. Which it can, because it’s Google’s CDN.

AMP is not the web. Yet

When AMP was first released, there was a good amount of activity in the web standards world towards something that could look the same. The initial efforts have consolidated into Feature Policy, which is centred around the idea of opting out of specific web platform features to provide a better experience to users. This is a fantastic idea, and I think even more powerful than AMP: it could allow browsers to make optimisations for pages that give themselves strict requirements. But this is very early work in a field that moves very slowly.

The other missing piece is better support for– and more control over– Resource Hints. If Google Search could use it to the same effect as it does the AMP viewer, it would do away with the need for the (centralised) AMP Cache, and also solve the issues around sharing URLs.

I think it’s telling that Paul Bakaus describes AMP as a “stopgap measure”: web platform features can and should be capable of this in the future.

Further Reading