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.
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,
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
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.
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
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.