We’re Bullish on AMP

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

There are things about AMP that are tricky. The actual structure of it is kind of squishy—you put arbitrary <amp-*> tags into HTML…Google takes it from there. That said, there’s a reference (if not quite a fully fleshed-out standard?), much development is carried out in the open, and the thing that is displayed is ultimately, still a web page, in a web browser—with the legacy ads in iframes, and no chance for JavaScript to block the page from loading, and plenty of support for ZergNet embeds. So it’s still the web in all its wonderful, crappy, awesome glory.

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

Binders full of pages color-coded for easy retrieval

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.

So there’s no Python or PHP or JavaScript library where you can just fetch all the resources and have them addressable as a single in-memory object for processing and caching. The work just hasn’t been done yet. What would be exciting is the ability to cache lots of AMP resources inside of a mobile app, inside of a web app, and on a server, or in a cloud service like S3. Then you could start to build things like the Amazon Video app, or the Kindle app.

Problem #2: Lack of second-party discoverability

These poor toucans

Google has over 100+ million AMP pages on record, but you can’t search through just that data set, or list them or explore the metadata around them. It’s all optimized around Google’s search, and Google isn’t usually that into people exploring its data in ways that could be used to create new search products. This isn’t their fault per se, they’re just a business like the rest of us. But: You could bootstrap a variety of solid news/ad/search/promotional products on top of an AMP-focused search/feed engine (someone asked us to explain this a little further). At some level this is the future of “mobile first.” And you could see a future take on RSS right here, in fact—incredibly fast mobile infrastructure, rich media, a variety of content types, and decentralized. Feeds everywhere! Cached for offline reading! With ads embedded and publishers still able to monetize and readers still able to read whatever they hell they want! With video! Cats and dogs, writing Javascript together!

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.