Now that AMP has publicly launched on Google Search and many other platforms (i.e WordPress), it’s time to start thinking how we can bring the things that work in AMP to the broader web.

AMP isn’t for everyone (yet)

Going one step back, I want to reiterate that the current AMP is currently not a broad solution for the web at large. There’s been lots of questions about this, and I take part of the blame for not answering them. In making oversimplified statements such as “AMP makes pages fast”, we didn’t always make it clear that AMP is currently optimized for static content pages like news articles.

That’s right! A lot of the performance and content optimizations that are part of AMP don’t make sense for other web content yet – like not being allowed to have scrollable sub-elements, or modals, or being forced to statically layout the whole page in advance.

So chances are that if you don’t create static content pages, today’s AMP isn’t for you. But that’s okay, because the AMP team is already thinking hard about how to take what’s cool about AMP and distill it into a open, easily accessible standard.

From AMP to CPP

Our own preliminary thoughts on how to do this are very similiar to Tim Kadlec’s and Yoav Weiss’ thoughts. The idea here is to create a CPP – a Content Performance Policy (analogous to CSP) that is specified in the header of a page and enforced by the browser.

You can build a site that’s as fast as an AMP site, but the biggest advantage of AMP is that it offers confirmation that the page is in fact fast – the built-in validation helps platforms offer users the real deal. A defined CPP could be easily parsed by content aggregators and platforms, and if these platforms know that browsers enforce the rules defined in it, we might, in theory, get pretty close to a validation system.

More than just performance

But maybe a CPP isn’t the right approach for standardization. AMP’s goal is to deliver a great user experience to static content pages, and that encompasses more than just being fast. For example, the following rules are not strictly associated with speed:

  • Static layout enforcement (helps with prefetch, but also makes your page not jump around while a user is reading it)
  • Support for optimized prerendering.
  • Distributed cacheability.
  • Disallowing popups or modals.
  • Disallowing scrollable containers (only the page may scroll vertically).

These are clear improvements to the user experience, but won’t make a page faster. Framing them under a CPP wouldn’t work.

Things that are slow today might not be slow tomorrow

Another challenge to standardization is the fact that browsers evolve fairly quickly, which is why a lot of web developers are advocating for “tools, not rules”. For example, CSS Box-Shadow might have been a no-no years ago, but is actually fairly OK in today’s Chrome.

Therefore certain rules, like only allowing opacity and transform in CSS Transitions and Animations, are most certainly going to be useless in the future. We are getting away with it in AMP as the AMP JS library is always linked to externally from AMP pages, so we can always quickly roll out updates in the future, but a standard doesn’t have that luxury.

Please help

We’ll need your help to figure this out. As mentioned earlier, AMP is currently optimized for static content pages, and we now need to figure out which of the enforced rules are applicable for all of the web, and which aren’t.  I’d argue that stuff like disallowing document.write is unequivocally a good idea, but disallowing external stylesheets probably isn’t.

And maybe a Content Performance Policy isn’t the right approach – maybe we need something more generic, something like User Experience Interventions.You’d be able to mix and match them in the header of your page, and and it’s up to any site crawler to make assumptions whether your site conforms to their quality standards.

If you have ideas or suggestions, join the conversation and get in touch with me or Malte. Let’s make this happen.