Today Google launched the Accelerated Mobile Pages Project, or AMP for short. According to the launch blog post:
Today, after discussions with publishers and technology companies around the world, we’re announcing a new open source initiative called Accelerated Mobile Pages, which aims to dramatically improve the performance of the mobile web. We want webpages with rich content like video, animations and graphics to work alongside smart ads, and to load instantaneously. We also want the same code to work across multiple platforms and devices so that content can appear everywhere in an instant — no matter what type of phone, tablet or mobile device you’re using.
Improving performance is obviously a great goal, and it’s one that’s sorely needed in today’s mobile web. Further, AMP is widely seen as a response to Facebook’s Instant Articles and Apple’s News, both of which define new content formats for embedding publisher content into their native apps. The key difference between those projects and AMP, according to Google, is openness and AMP’s use of existing web technologies.
But how open is AMP, and how different is it from Instant Articles and News? And what does AMP’s technical implementation say about the state of the existing mobile web?
AMP HTML is HTML Circa 2000
The core of AMP is a new HTML subset called AMP HTML. From my preliminary read of the AMP HTML spec, most of AMP’s speed-up seems to come from ripping out a bunch of features from modern HTML. This includes, among other things:
No external CSS: AMP allows exactly one block of CSS written by the content author, and it must be inlined to the HTML page.
No complex CSS selectors: There are only a few simple CSS selector types that can be used, like .class and #id.
No <input> tags: AMP is envisioned as a technology for static pages only, and all input tags that might collect user input are eliminated.
No media tags that don’t have a width/height: All image and video tags have to have statically defined width and height to prevent re-renders.
The end result is an extremely stripped down, very fast page… with zero user interactivity. In its pursuit of speed, AMP HTML removes almost all of the last 15 years of advancements to the open web platform.
But what about my Slideshow Listicles?
The authors of AMP know, however, that they will need to have some level of interactivity to meet the demands of modern publishers, not least for advertising and user tracking. The solution they came up with to bridge HTML2000 to the experiences of today: Web Components.
AMP builds in several Web Components as part of its platform, most notably amp-img and amp-video, which are meant to replace the HTML img and video tags (oh right, I forgot to mention above that the HTML img and video tags are also forbidden in AMP HTML!). The AMP project also includes some built-in Web Components for ads, tracking pixels, polls, photo lightboxes, and a few other functions.
But what if you as a publisher want to add some piece of interactive content that hasn’t been anticipated by the AMP project? As far as I can tell from the documentation, you need to create an “extended component”, attempt to contribute that component to the AMP project, and await the judgment of the AMP project folks:
The creators of the AMP component project — Google and a core group of collaborators, and potentially representatives from other collaborators as the project grows in usage — will have ultimate discretion as to the inclusion of contributed components, though with the goal of including every high-quality contribution that meets the above guidelines, and resolving or providing feedback on proposed contributions in a timely manner.
Presumably, Google and the other collaborators will vet the component to make sure it is speedy and follows (as yet unspecified) best practices. If you don’t meet those requirements, though, it looks like you can’t include the functionality in your AMP page.
It’s possible that the AMP Project will develop clear, easy-to-follow guidelines for component inclusion with a transparent governance process, but that’s far from clear as of yet. At worst, the process could be akin to needing an AppStore approval for the mobile web.
AMP’s Open Web is neither “Open” nor “Web”. Discuss.
What we are left with, from my view, is a great spec for fast mobile pages and an (at best) Pyrrhic victory for the open web.
What has long excited me about the “open web” as a platform is its lack of a strong central authority regulating publishing and its near infinite programmability. It feels like both are being diminished with AMP. The severe restrictions in AMP HTML impair programmability, and the approval process for Web Components installs an authority who gets to determine what new kinds of content are allowed. Seen this way, AMP is an Open Web solution, but one that has lost both the “Open” (no central authority) and the “Web” (programmable platform).
I should say here that engineering is of course about tradeoffs, and I understand the constraints that Google is working under here: they want pages to be provably fast and to display in current browsers (which is a critical, important benefit of AMP over Instant Articles or Apple News). I get why they made the choices they made.
However, it’s hard for me to see AMP as a victory for the future of the mobile web, because it points out how much page speed trades off against the things that make the web platform great. If the very smart engineers at Google have determined that we can’t have speed, programmability, and openness all at the same time, the mobile web platform as we know it is clearly in a troubling, and very deep, crisis.