AMP stands for Accelerated Mobile Pages. It’s an open source spec created by Google and collaborated on by a number of other mega companies, in response to Facebook’s “Instant Articles” feature.
The tl;dr on AMP is that it’s a not HTML but like HTML implementation of web pages that supports limited web features, and importantly prevents JavaScript from running. Implementation-wise, it feels a whole lot like working with print stylesheets to me. They have a whole “how it works” bit though, that I’d recommend you check out.
Websites can support AMP using a separate view. Images, video, and audio are allowed, but a lot of stuff (like non-common embeds) are not supported. Tracking and analytics are not supported — though they are supporting a tracking image like is possible in email, and more controlled analytics solutions will be made available to support common software like Google Analytics.
Stylewise, it depends on the implementation, but basic typography and header/footer customization is possible. The current WordPress implementation looks like the Jetpack mobile theme essentially, and it was released along with the announcement of AMP by Automattic.
Those style and template options will improve. It’s available for .org and WordPress.com through the same Github repo.
By far the best article you’ll read on AMP is by Joshua Benton on Nieman Lab. Absolutely read this article. He rightly has mixed feelings.
There are a ton of smart ideas in AMP. And it works — cutting the load times of article pages enormously.
But I have to say I’m a little conflicted about it. Google notes that AMP isn’t a business partnership the way that Instant Articles or Apple News are; there’s no ad rev share to consider. But AMP tries to do something maybe even more significant: change the way that the web is built, killing off some technologies and advantaging others. In a world of controlled platforms and walled app gardens, the web is the last open space standing, built over two decades, and there’s something irksome about a few Google engineers deciding which parts to ban.
Yes, publishers don’t have to adopt it, and yes, it’s an open source project, and yes, the performance gains are very real and very substantial. But publishers can choose to adopt Facebook Instant Articles and Apple News too. The point is that this is another stop on the path to powerlessness for publishers — another case of tech companies setting the rules.
For readers, AMP is an undeniable win. Benton highlights the Verge’s speed gains by supporting it, and what they give up:
On my iMac, the full version weighs in at 1.3 megabytes, renders the visible content in 2.60 seconds, and loads completely in 5.80 seconds. The AMP version is about half the size (777 kilobytes), renders in 0.47 seconds, and loads completely in 1.34 seconds.
That’s the kind of enormous speed gain we’re talking about. But…that page also includes a SoundCloud embed — which is just broken in the AMP version, presumably because there isn’t an
amp-soundcloud, or The Verge hasn’t implemented whatever it needs to make it work. And…The Verge is giving up whatever benefit they were getting from all those ad trackers and analytics trackers and such.It is possible to believe both that (a) there are too many ad tech companies and too many sloppy ad networks and too many duplicative analytics packages and the web is a giant mess, and (b) that publishers don’t add those things to their pages purely to annoy users, and they get some form of (financial, analytical, editorial) value from them. AMP makes those choices for them.
It seems clear to me that AMP is going to be a clear part of a web developer’s future. Consider “Will it support AMP?” the potential client question of 2016 like “Will it be responsive?” was in 2012. Eventually (probably quicker than RWD), it’ll be standard for “generic” content — and it may never be appropriate for some landing pages and corporate sites — but it’s going to take a few months for people to figure things out.
