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:
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
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:
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:
CPP vs AMP: https://timkadlec.com/2016/02/a-standardized-alternative-to-amp/
Scaling it: https://paulbakaus.com/2016/02/26/life-after-amp/
Twitter’s link shortener will one day fail, so I’ve added the links into the source of the tweet.
Update: October 15, 2016
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.
Update: November 17, 2016
Google’s AMP lies to us about news sources, owing to the Google.com 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
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 https://encrypted.google.com/ 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.
Update: May 22, 2017
The Register has an opinionated piece about AMP, as suggested by its title: Kill Google AMP before it KILLS the web. For good measure, it also has “bad_bad_bad” in the URL.
It does not hold back:
Google’s AMP is bad – bad in a potentially web-destroying way. Google AMP is bad news for how the web is built, it’s bad news for publishers of credible online content, and it’s bad news for consumers of that content. Google AMP is only good for one party: Google. Google, and possibly, purveyors of fake news.
TechCrunch isn’t as overtly anti-AMP, but it does make an observation about Google’s I/O event:
[T]oday Google is introducing coding for three new ad formats. […] [I]t’s no surprise at all that [Google’s] efforts to improve the mobile user experience have moved into improving the mobile advertising user experience.
John Gruber reiterates his dislike of AMP:
It implements its own scrolling behavior on iOS, which feels unnatural, and even worse, it breaks the decade-old system-wide iOS behavior of being able to tap the status bar to scroll to the top of any scrollable view. AMP also completely breaks Safari’s ability to search for text on a page (via the “Find on Page” action in the sharing sheet).
Pixel Envy also gives us a perspective worth noting:
[W]e cannot ignore Google’s slow takeover of the web. The world wide web is slowly becoming a Google product, and that’s just as fundamentally flawed as if the web were a division of Comcast.
Update: August 25, 2017
The article talks AMP, but if iOS11/Safari leans on canonical URLs (yay!) on shares, then impacts Medium as well: https://www.theverge.com/2017/8/23/16193584/ios-11-safari-google-amp-sharing-url-scheme
Update: August 28, 2017
On last tweet, I explicitly adjusted URL so it would not be an AMP page. But mobile Twitter adds ?amp=1 to URLs in its t•co shortener now.
This is probably to improve perceived performance for those who allow Twitter to open links in its own browser. http://searchengineland.com/twitter-ramps-amp-278300
Update: September 2, 2017
Ethan Marcotte points out two troubling developments (Stamp and a framework), and echos what I have been arguing all along — just use a set of guidelines that are based on standards.
What’s more, AMP’s scope is expanding. There’s talk of an upcoming AMP variant called “Stamp”, an extension of the framework that’d provide a Snapchat-like, media-friendly experience for publishers (and their advertisers). But I’m also given to understand Google’s about to position AMP as a general site-building framework, similar to Bootstrap or Foundation. […]
[…] But that aside, I can’t help but wish Google had approached their “Accelerated Mobile Pages Project” differently, perhaps as a set of guidelines. Rather than creating a parallel HTML standard, and leveraging Google’s own search results to incentivize adoption, I wish the AMP had defined a set of criteria that could’ve been validated by, say, Google’s own Lighthouse project.[…]
Update: September 10, 2017
This has all happened before.
Update: October 30, 2017
Jeremy Keith has called out Google’s constant mis-characterization of how AMP pages appear in search results:
At AMP Conf, the Google Search team were at pains to repeat over and over that AMP pages wouldn’t get any preferential treatment in search results …but they appear in a carousel above the search results. […] This is the only reason why The Guardian, for instance, even have AMP versions of their content—it’s not for the performance benefits (their non-AMP pages are faster); it’s for that prime real estate in the carousel.
This is, in my opinion, the only reason that AMP still has any legs with publishers. It certainly isn’t from guaranteed speed or control over hosting. It’s because Google has a lock on the search engine space and publishers have no choice but to play ball.
Ethan Marcotte tears apart the notion that AMP is open in anything but the most basic sense.
So, yes. The HTML standard does allow for the creation of custom elements, it’s true, and AMP’s license is quite liberal. But spend a bit of time with the rules that outline AMP’s governance. Significant features and changes require the approval of AMP’s Technical Lead and one Core Committer—and if you peruse the list of AMP’s Core Committers, that list seems exclusively staffed and led by Google employees.
Those who play in open source already know that putting something on GitHub and telling people that they contribute is usually an easy way of dismissing those who have valid concerns with a project. It immediately limits participation to only those who have the free time and the specific technical skills, which will never compete with the corporate team paid to know the technology and staff the project.
Update: November 21, 2017
Good thing AMP has guaranteed smaller pages without all the cruft!
The internet is doomed.amp.thedailybeast.com/ceo-of-hq…
Update: December 26, 2017
Good thing AMP doesn’t require a specific browser!
This is what I get on a slow connection when I click on links in the Google app and immediately ask the custom tab to open in Firefox (I have to wait a bit)
This does not happen if my default browser is Chrome and seems to be an AMP issue.
Stop breaking the web with AMP. pic.twitter.com/fXN9y7Grwb
Oh, hey, copying that 404 URL into chrome works great.
What the fuck, Google? You're giving 404s based on the browser now?
At least have the decency to give an unsupported browser message so I know what's going on.
Update: December 28, 2017
Remember that Ajit Pai used Google AMP to justify killing Net Neutrality (only one of many arguments, of course):
And many [Silicon Valley companies] thrive on the business model of charging to place content in front of eyeballs. What else is “Accelerated Mobile Pages” or promoted tweets but prioritization?
Ethan Marcotte builds on that to discuss zero-rating and net neutrality:
The more I’ve thought about it, I think there’s a strong, clear line between ISPs choosing specific kinds of content to prioritize, and projects like Google’s Accelerated Mobile Project. And apparently, so does the FCC chair: companies like Google, Facebook, or Apple are choosing which URLs get delivered as quickly as possible. But rather than subsidizing that access through paid sponsorships, these companies are prioritizing pages republished through their proprietary channels, using their proprietary document formats.
Update: January 8, 2018
This is not a unique sentiment.
AMP brands itself as good for the web and improving user experience, but ultimately it’s just proven itself as a way to game search results with a side effect of speed sometimes.
Update: January 9, 2018
AMP may lean on a web standard for its caching, which I of course applaud.
We embarked on a multi-month long effort, and today we finally feel confident that we found a solution: As recommended by the W3C TAG, we intend to implement a new version of AMP Cache serving based on the emerging Web Packaging standard. Based on this web standard AMP navigations from Google Search can take advantage of privacy-preserving preloading and the performance of Google’s servers, while URLs remain as the publisher intended and the primary security context of the web, the origin, remains intact. We have built a prototype based on the Chrome Browser and an experimental version of Google Search to make sure it actually does deliver on both the desired UX and performance in real use cases. This step gives us confidence that we have a promising solution to this hard problem and that it will soon become the way that users will encounter AMP content on the web.
You will note I explicitly did not link to the AMP version of that page (which performs worse than the AMP page simply because of third-party scripts and fonts that could, you know, just be excluded).
I intentionally left the weird
<span>s in place in the underlying HTML of that quote from the AMP page (which are different and use more characters than the non-AMP version of that page).
Separately, an open letter appeared today asking Google to be more transparent and stop promoting AMP pages in search results.
If Google’s objective with AMP is indeed to improve user experience on the Web, then we suggest some simple changes that would do that while still allowing the Web to remain dynamic, competitive and consumer-oriented:
- Instead of granting premium placement in search results only to AMP, provide the same perks to all pages that meet an objective, neutral performance criterion such as Speed Index. Publishers can then use any technical solution of their choice.
- Do not display third-party content within a Google page unless it is clear to the user that they are looking at a Google product. It is perfectly acceptable for Google to launch a “news reader”, but it is not acceptable to display a page that carries only third party branding on what is actually a Google URL, nor to require that third party to use Google’s hosting in order to appear in search results.
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?