Google’s AMP HTML

Google wants to speed up the web, and it has a plan:

For many, reading on the mobile web is a slow, clunky and frustrating experience – but it doesn’t have to be that way. The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere.

Ramble Ramble Ramble

I’ve been wanting to dive into this topic all weekend. I started this post, I stopped this post, I came back to it, I let it lapse. In the end, others have already written thoughts about AMP HTML that are better than I could have rambled through on my own, so I am collecting some of them here (via links and some quotes).

Right off the bat, if you use the AMP project page to get a sense of how capable Google is of doing this right, you may become a little deflated. For starters, it fails on the accessibility front, lacking alt text on images, a lang attribute on the <html> element, controls on its opening video, and sufficient text contrast. It also seems to demonstrate just why we want faster pages by itself weighing in at 44MB over 124 requests, taking nearly 6 seconds to load as Mat Marquis demonstrated: page load analysis: 124 requests; 44MB transferred; Finish: 2.7min; DOM Content Loaded: 4.2s; Load: 5.45s
Mat Marquis

But that’s just the marketing page. That isn’t the AMP HTML spec itself (though maybe it’s trying to prove its own value?). Thankfully you can find it on GitHub and will see this very comforting opening (if you’re into standards-based development):

AMP HTML is a subset of HTML for authoring content pages such as news articles in a way that guarantees certain baseline performance characteristics.

Being a subset of HTML, it puts some restrictions on the full set of tags and functionality available through HTML but it does not require the development of new rendering engines: Existing user agents can render AMP HTML just like all other HTML.

Once you wade into the spec itself you will find that it does not, in fact, exist as a sub-set of HTML, but essentially a forked version. When you start minting new attributes that already exist in HTML, but for completely different purposes (in one case, placeholder), you have to agree with Jeremy Keith’s response:

Um. At some point, you may have to stop referring to AMP HTML as a subset of HTML and just say it’s a different language, because, well, if you invent attributes like this, it is.

If you read that entire bug thread, you might have a better sense of how there is little attempt here to truly exist as a sub-set of HTML.

For example, I feel that <amp-img> is an over-engineered replacement for <img>. While it allows srcset, I think leaning on the entire responsive image spec would be easier to track and promote consistent use. I also believe lazy-load feature could be explored using the <template> approach described by Christian Heilmann.

There are other places where the requirements fly in the face of good UX, such as this bit on defining the viewport for responsive layouts to prevent zooming (though there is a bug open to correct it [update below]):

AMP HTML documents MUST

  • […]
  • contain a <meta name="viewport" content="width=device-width,initial-scale=1,minimum-scale=1,maximum-scale=1,user-scalable=no,minimal-ui"> tag inside their head tag.
  • […]

There are other bugs tagged accessibility, and I hope to see more added to the list as there are a lot of curious decisions in the spec right now.

Even Longer (But Less Rambly) Reads

Tim Kadlec has a good post, AMP and Incentives, that I think sums up much of this rather nicely:

AMP isn’t encouraging better performance on the web; AMP is encouraging the use of their specific tool to build a version of a web page. It doesn’t feel like something helping the open web so much as it feels like something bringing a little bit of the walled garden mentality of native development onto the web.

Jeremy Keith has written a sort of FAQ in AMPed up that, in addition to being a great list of questions, has a great opener:

Apple has Apple News. Facebook has Instant Articles. Now Google has AMP: Accelerated Mobile Pages.

The big players sure are going to a lot of effort to reinvent RSS.

Update: October 13, 2015

It looks like the viewport code that prevents zooming will be corrected, per the approved update this morning.

Update: February 29, 2016

I linked some stuff:

Twitter’s link shortener will one day fail, so I’ve added the links into the source of the tweet.

Update: October 15, 2016

A Google employee argues for AMP on his personal blog, but does not disclose his role at Google is “Developer Advocate, Chrome DevTools & AMP” (per LinkedIn).

Since his blog has no way to leave comments, a good discussion spins up on Hacker News.

Update: October 23, 2016

That error message (Sorry, this page is not valid AMP HTML.) is exactly the reason (well, one of many) that XHTML2 never went anywhere. Malformed HTML still gets rendered, malformed XHTML2 did not. That strictness prevented it from gaining any traction.

So yeah.

Update: November 17, 2016

Google’s AMP lies to us about news sources, owing to the URL:

There is an issue open against the AMP project if you want to see any of the additional commentary and notes.

Update: January 17, 2017

Thanks to a tweet from Chris Heilmann today I discovered that Baidu has released its own version of AMP, called Mobile Instant Page (MIP).

Boy, if only Baidu belonged to some standards body that could help prevent this kind of fracturing across the web. Oh wait, it does. Just like Google.

Update: January 18, 2017

Kyle Schreiber has a post, The Problem With AMP, that while not presenting anything brand new does remind us that in well over a year AMP has not quite gotten there. Granted, all standards processes take forever, but at least anyone can participate and they are mostly consistent when applied. His post does remind us that exists and is a viable search alternative if you want to still use Google.

I also came across this piece by Jonathan Schofield titled Trump, Google’s AMP Project, and the law of unintended consequences. He details his own struggles with trying to find the original, canonical article he is reading through AMP and finds an iframe lurking in the midst.

Update: March 8, 2017

Going on right now is the AMP Conf, which is being live streamed if you have the time to watch. I do not have the time to watch, but Tim Kadlic watched the AMP & the web platform talk and wrote some of his thoughts at AMP and the Web.

He notes that the panel, overall, claims that organizations are not choosing AMP for performance reasons, but for SEO reasons. Being an AMP page gives it a badge and a priority location in the carousel.

Sadly, this is corresponds to why I have found myself using Google as a search engine less and less. I want results for my query, not results based on which pages get promoted for following Google’s own technical requirements.

Update: March 13, 2017

Jeremy Keith attended the AMP conference:

This is one of the reasons why AMP feels like such a bait’n’switch to me. […] But the big difference, we were told, was that you get to host your own content. That appealed to me much more than having Facebook or Apple host the articles. But now it turns out that Google do host the articles.

One Comment


Do Google expect the W3C to update HTML5 by adding their additional elements and attributes?

Because then I don’t think Google understand the purpose of HTML. It is a general document format. It should not carry implementation-specific features such as “amp-boilerplate”, whose very name refers to Google’s project.

Do they think that the name “amp” belongs up there with “content” and “encoding”?
Or do they intend to keep the AMP format separate forever from HTML?

Leave a Comment or Response

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>