When Google unveiled its solution to the problem of mobile web browsing congestion yesterday, it was celebrated as an a more open solution than Facebook Instant Articles.
Google’s AMP (Accelerated Mobile Pages) uses a subset of open technologies to speed up the delivery of webpages. The use of the word “open” should be pleasing to your ears, but Tim Kadlec points out that AMP doesn’t encourage web publishers to improve the mobile performance of their sites so much as it incentivizes the publishers to use AMP’s tools:
The advantage that AMP has over anyone else who might try to make similar claims is that AMP provides clear incentive by promising better methods of distribution for AMP content than non-AMP content.
The distribution model is slightly more fuzzy at the moment than the performance impact, but with a little imagination you can see the potential. The AMP Project is promising a much-needed revenue stream for publishers through soon to be added functionality for subscription models and advertising. Google, for its part, will be using AMP pages in their news and search products at the very least.
I think it comes down to incentives.
If you can build a site that performs well without using AMP, then what does AMP offer us? Certainly convenience—that’s the primary offering of any framework. And if AMP stopped there, I think I’d feel a little more at ease. I actually kind of like the idea of a framework for performance.
It’s the distribution that makes AMP different. It’s the distribution that makes publishers suddenly so interested in building a highly performant version of their pages—something they’re all capable of doing otherwise. AMP’s promise of improved distribution is cutting through all the red tape that usually stands in the way.
This promise of improved distribution for pages using AMP HTML shifts the incentive. 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.
Incentives can be a good thing. When Google pushed the web to adopt mobile-friendly site designs earlier this year, they incentivized web publishers with the threat of a hit to their SEO. At the same time Google did not tell anyone how to make their site mobile friendly; it just had to be done somehow, using any one of a half-dozen methods.
But when it comes to AMP, Google incentivizes web publishers to speed up their sites by using AMP and nothing else, otherwise they won’t get the benefit.
Here’s an analogy that might explain it better. Since this is an ebook blog, let me put it in ebook terms.
Google’s AMP is to the open web what Apple’s iBooks format is to open ebook formats.
The comparison isn’t perfect (AMP is in fact more open than iBooks) but my point was that AMP and iBooks both use open tech and follow open standards, but the resulting product is not open. The incentives may be different (sales in iBooks vs SEO gains in Google), but there’s a fundamental similarity here.
Just like iBooks is a proprietary ebook format, AMP is a proprietary web tech – one which could ultimately cordon off a part of the web as Google’s fiefdom.
Fortunately, it is still the early days of the AMP project, and as Kadlec concluded:
There’s a smart team behind AMP and I do think there’s value in what they’re doing. I’m hopeful that, eventually, AMP will evolve into something that really does benefit the web as a whole—not just a specific version of it.
image by lucyrfisher