Here’s what publishers need to know about AMP…

What is it?

Google describes AMP as “an architectural framework built for speed” but it’s effectively a subset of the technologies publishers already use to build their websites.

Google has identified components of HTML, CSS and JavaScript that it believes aren’t critical and, most importantly, impede performance in mobile web experiences, and reigned them in as part of the AMP specification.

For example, iframes and third-party JavaScripts are not supported at all, and popular CSS features, like custom fonts, are restricted. 

Because some of AMP’s limitations would be nearly impossible for publishers to deal with, Google has created AMP HTML Components to provide support for functionality and design patterns that would be hard to live without.

There are components for embedding third-party content, such as YouTube videos, tweets and Twitter ads, as well as HTML tags like img and video. 

To create an AMP page, developers include boilerplate code and an AMP JavaScript library. More information is available through the project’s Github page.

What does it do?

Google describes the AMP project as an “initiative to improve the mobile web and enhance the distribution ecosystem” and explains that “AMP HTML is a new way to make web pages that are optimized to load instantly on users’ mobile devices.”

This is accomplished by:

  • Placing limits around the HTML, CSS and JavaScript that can be used to build pages.
  • Giving the JavaScript library that is included on every AMP page the responsibility of managing the page’s resources. Specifically, it loads and unloads resources as it deems appropriate.

Why did Google create it?

Mobile web user experiences are frequently far from optimal. Sites can be slow and clunky, and building performant mobile experiences can be difficult for publishers who have to grapple with ever-increasing fragmentation.

Google is positioning AMP as a solution to these problems.

Not everybody, however, believes that Google’s motives are entirely altruistic. Google has a vested interest in influencing the mobile web because a big part of its business is serving mobile ads.

Google’s vision of a faster, more reliable mobile web sounds good on paper, but it’s not clear that what critics might call a watered-down subset of HTML will actually lead to better user experiences in practice.

Some even imply that AMP could give Google a leg up on competitors in the ad space. They point out that by forbidding third-party JavaScripts, Google could make life tough for other ad networks, most of which deliver their ads using JavaScript.

While there’s technically nothing stopping them from becoming supported by AMP’s ad component, initially only a handful of major ad providers, including Google, are supported by this component.

Why is it important?

Google has made its desire to influence the mobile web known, but with AMP, Google looks to be trying to reshape the future of the mobile web.

Instead of addressing the issues around mobile experience with a proprietary, hosted offering like Facebook Instant Articles, Google has, as some are pointing out, created its own version of HTML released under an open source license and available for any publisher to use.

While there’s no indication that Google will give a boost in the SERPs to publishers that use AMP, the search giant is already weighing mobile-friendliness and rewarding publishers that allow Google access to index their native app content, so it wouldn’t be entirely surprising to see this change at some point in the future.

Why it might not be important

AMP is a bold initiative, but that doesn’t mean it will be successful and there is already a decent amount of legitimate skepticism.

From questions about Google’s motivations to questions about whether the type of interactive experiences consumers want are possible with such a limited set of HTML and CSS, Google faces an uphill battle in driving AMP adoption.

While publishers like The New York Times, Guardian, Daily Mail and BuzzFeed are touted as AMP partners, it’s hard to imagine that most publishers are going to serve up two versions of their site’s pages unless it becomes incredibly easy and there’s a significant enough incentive.

WordPress, the world’s most popular open source content management system, already has an AMP plugin that’s being tested, and other CMS makers will no doubt build AMP support.

But unless publishers see tangible benefits from AMP, namely increased usage and conversion metrics, higher revenue and, perhaps, higher search rankings, AMP is far from a sure bet.

What should publishers do?

Forward-thinking publishers will no doubt want to track AMP’s progress and possibly even experiment with building AMP pages.

But until the AMP project offers up better code samples and there exists validation of AMP’s benefits in the form of real-world case studies, most publishers will probably want to take a wait-and-see approach before supporting AMP in production.