The Accelerated Mobile Pages Project, or AMP for short, is considered to be Google’s answer to Facebook’s Instant Article format. Free and open-source, this framework seeks to enable faster-loading pages for mobile devices. The incentive for publishers to actually use AMP is Google’s promise that faster-loading content will appear at the top of its results list. So far so good.
More specifically, AMP is a restrictive framework for dynamic delivery models. Google hasn’t broken any new ground: for faster loading, just restrict content for loading.
It’s no secret that the main culprits of slow-loading pages nowadays are the ever-present javascripts, used mainly for marketing purposes. AMP has come up with a simple solution: its format precludes the use of these scripts, or any other custom script, or third-party scripts. How radical. Sheer genius.
But there are other culprits apart from javascripts, and Google’s response to these is similar. Is the page’s design too heavy? No problem: just strip it out. In practice, this means, for example, that CSS declarations must be inline (in HTML code) and limited to 50kb, and only pre-approved asynchronous scripts (scripts that can be loaded in the background after the page displays) are allowed.
If you like using JavaScript libraries such as jQuery, Bootstrap, Angular, or React, you’re out of luck; you’ll have to make do with a single, very basic library, AMP JS. In other words, AMP deals only with static content such as press articles; you can forget AMP for anything to do with Web applications.
Advertising can only be displayed in amp-ad tags and only if it comes from preselected networks, like Google AdSense. This of course will make the work of ad blockers that much easier.
What’s hot
User Experience
The biggest winners of AMP are users. Cleaner, mostly ad- and tracker-free pages are more pleasant to look at and much faster to load. Chances are that users will load that many more pages on an AMP site, just like on a traditional, well-designed and optimized mobile site.
What’s not
Web fragmentation
Facebook Instant Article, Google AMP, Apple News, and who knows what’s next… that’s a lot of different formats for a marginal cost-benefit ratio.
Regarding Google’s format specifically, it’s really not that hard to create dedicated pages for mobile devices with HTML/CSS that are just as fast as AMP, if not faster. Which begs the question: was it really necessary to create a non-standard HTML sub-set to be efficient on mobile platforms? Unless the real intent is to throttle content and deprive publishers of some of their freedom to decide on the way their articles are displayed, and the way they generate revenues.
The proliferation of these more-or-less proprietary formats will also make life difficult for publishers. Rather than creating a single mobile version, publishers will have to create a different version for each platform, under pain of being penalized with lower placement on the results list. Of course, Google, through Dave Besbris, the VP in charge of the AMP project, denies any such intent, asserting that Google will not give AMP pages preferential treatment. Which makes us wonder where their interest lies. In any case, the facts belie Besbris: AMP pages are indeed given preferential treatment in Google Search, with carousel presentation for press sites: quite the exception. On Facebook, the situation is just as murky.
So, to sum up: normal Web version, adaptive Tablet version, Facebook version, Google version and, if you are a press publisher, Apple version… the development and maintenance costs quickly add up. And this flies in the face of the promise of an open, accessible and interoperable Web: each page accessible to all, regardless of hardware, access network, operating system, browser, etc. Instead of improving the mobile experience for all, we’re fragmenting the Web into subsets: traditional, Google, Facebook…
Hard to capitalize on
AMP pages currently generate little traffic. Two publishers who offer AMP-formatted pages, Slate and The Atlantic, say these account for less than 4% of total traffic. Hard to sell these pages to advertisers, especially since AMP authorizes very few advertising formats and chances are that the framework will indefinitely preclude pop-ups and other interstitial formats that are particularly popular with advertisers.
Reason for concern
The Google ecosystem is littered with dead projects. It is entirely possible that Google will eventually stop actively supporting AMP, which would signal the beginning of its slow and inexorable death. Remember, the main incentive for publishers to use AMP is to appear at the top of Google Search results. Without the active support of Google (who, in practice, does give AMP pages preferential treatment), the format would lose most of its charm for content producers.
In conclusion
By using the same strategy AMP uses (drastically reducing queries, javaScripts, and CSSs, CDN use, etc.), it is perfectly possible to create mobile sites that are as fast as AMP sites, while remaining within Web standards and keeping the option of avoiding restrictions deemed to be excessive. Since Google promises that normal sites will not be treated differently from AMP sites, as long as its mobile performance is up to scratch, it is difficult to see any real advantage to Google’s format, especially when you take into account its drawbacks and restrictions. If Google does not keep its promise, i.e. if it does give its proprietary format sites preferential treatment, it is up to you to decide whether enhanced Google Search visibility makes up for the extra investment and inconvenience.
