Google is now planning to show AMP links everywhere in its mobile search results — that is to say, in a place that probably drives a lot of traffic to your site. Wherever there’s an AMP page, Google will display it in the result (with an accompanying AMP lightning bolt). —“Google AMP is about to become a much bigger deal, showing up in everybody’s mobile search results,” Shan Wang, NiemanLab, August 2, 2016
The way AMP (Accelerated Mobile Pages) works is, you make a special version of your web page that behaves itself. Just a normal web page with some extra tags added, and a few bad things (like slow ads) removed.
When Google comes along to spider your site, it notices that you put in a link to that well-behaved page. It saves a copy of the whole thing, pictures and all.
Now Google has that copy at the ready, and should someone on a smartphone request it, Google can pop the whole thing up—words, images, scripts—in less than a second, even on a slowish network. It’s nice.
Postlight ❤ AMP, mostly
We—Postlight—like AMP because as technology things go, it’s pretty simple to understand. We liked it enough that a few months ago we built and launched a new service called Mercury, that converts any web page into an AMP page.
We haven’t talked about Mercury too much after launch—it’s been working for us and bringing new people to the door of our agency. We’re converting the URLs. More emails (and bug reports!) are coming in as people use it more. And we definitely see Mercury (and AMP) as worth the effort; we’re planning to expand upon it going forward. Meanwhile, external to our slice of the world, the number of ad networks supporting AMP directly is growing, the number of publishers is increasing, and the number of content types directly supported is also increasing—Digiday suggests that AMP will soon support “articles, videos, live videos, galleries, quotes, listicles and more.”
It’s not all great, though
But what’s trickier still is that Google has de-facto control of AMP. This isn’t the result of some evil conspiracy. It just means that development keeps moving in a particular direction.
It’s easy to imagine that there are two Googles: The good one, in five-toed-shoes and a T-shirt, riding a bicycle, that believes in an open web and is super-nerdy and builds great stuff, and the bad one, in a suit and wingtips, that jets from office to office and shuts down Google Reader and controls a huge amount of the world’s technology infrastructure in the interest of its advertising business. But there is, of course, only one Google, in competition with Facebook, Amazon, Apple, Verizon, and everyone else—and AMP is something they spearhead and control.
AMP solves a lot of lingering problems. AMP representations of HTML content are readable, valid, structured, and tend to be small in size. AMP is a natural baseline format for any reactive, responsive, cross-platform media distribution platform you decided to build.
What kind of platforms? Let’s say I wanted to create a competitor to Kindle and I needed a format for the text that would work across devices. Let’s say I wanted to build a new YouTube that attached a poem to every video. Or to make a really easily embeddable web page that could go inside other web pages in an iframe. Or a new kind of reactive, flexible native advertising unit that could fit anywhere.
To build things like this you need a baseline standard and those baselines are surprisingly time-consuming to identify and lock down. Thus saying “we’ll build on top of AMP” is solid, defensible technological decision.
I know this sounds kind of dumb. “Just use JSON!” you might say. Or: “HTML5 works fine without this extra stuff!” “You don’t need AMP for that, you can use responsive design.” Or “Just don’t allow ads that block page loads!” All valid—and yet in reality those decisions come with costs. If you can cut thinking and testing time, cut out weeks and months of development, you can take other, more interesting risks, instead of trying to defensively figure out what will happen when the ad tag you insert from ProfitingsForPublishings.biz decides to replace every <img> on the page with cat butt pictures. This is why we’re fans of big, boring standards. Because they allow us to avoid lots of big, boring work.
So point made, Postlight likes AMP well enough. But there are two major downsides—real issues that need to be overcome before AMP can rise to its occasion.
Problem #1: Lack of second-party cache
Everyone outside of Google (including us!) is still focused on modifying current production pipelines to pop out AMP along with regular HTML. The sweet spot for AMP, though, is in the fast delivery and caching of whole pages to mobile devices in less than a second. The only thing that does that today is Google’s cache. As a result, Google controls the ultimate AMP experience, and it’s focused on its own needs and wants (i.e. fast-loading search results). There is an AMP API—you can ask for all the assets required to load a URL, and Google will give you a list of URLs. That’s all it does, though.
Problem #2: Lack of second-party discoverability
What’s cool about AMP is that it shows that there is still progress to be made when it comes to documents—bundles of words, images, typographically-informed, full of good and bad ideas—as opposed to shorter, more monochromatic messages. It also shows that publishers are still willing to opt-in to new standards, even if RSS has gone away. What’s less great is that there’s one company that has control over the platform. Google has the right approach for a single, centralized AMP-driven platform that integrates with the rest of Google’s offerings. But a broad-based, decentralized AMP-based platform that could be used to build new feed/browsing-driven products—that could happen too, and it could even bring a lot of feed-driven life back into the web.
Paul Ford is a co-founder of Postlight.