Google AMP : Accelerated Mobile Pages

The mobile takes a little more space in our lives every day and in our visibility strategies. But the weakness of this support remains the slow display of content. In line with Facebook and Apple, Google has been proposing the GPA project (Spss Mobile Pages) for several weeks, which will be installed on its search engine (and on many other sites including Twitter) in the first quarter of 2016. What is it about? How to integrate it on its site? Will they brought a gain in the positions of the pages that use this new standard? Here are the answers to all these questions (and others).

The year that has just ended has devoted both success and failure. On the one hand, mobile uses have developed impressively, and marked the beginning of an era where the dominant use will be to consult the Internet on a device other than a conventional computer. On the other hand, the main players in the Web found that mobile websites were still slow and did not offer an acceptable user experience over the long term.

The cause that leads to a slow display on a mobile device lies essentially in the use by publishers of unsuitable technical sites. The solution is therefore to advocate the use of more effective solutions. Facebook pulled the first by launching a new standard for content pages: the “Facebook instant articles”, announced in May, and which appeared at the end of September 2015 on the Facebook application. Then Apple launched Apple News.

In response, Google announced on October 8, 2015, the launch of its own project to create quasi-instantaneous pages on a mobile: ” accelerated mobile pages “.

How does this work? Is it necessary to adopt this new format now? What is the impact of the AMP pages on mobile referencing? What evolution does this project announce for mobile web technologies? So many questions we will try to answer in the following article.

What is the AMP pages?

” Spss Mobile Pages ” (accelerated mobile pages) are a new standard for mobile web pages development, officially supported by Google. The project was unveiled on October 7, 2015 at a press conference, with the participation of Twitter and WordPress who also support the project.

The AMP pages (which start calling the amplified pages) are designed to display as quickly as possible during a mobile consultation.

The project is based on both an open source development framework and an architecture provided by Google to display pages faster. All reference documents can be found on the project website: The speed gains of displaying the pages obtained are spectacular: on average, the gain would be in the order of a factor of 10.

Fig .1. A large number of American media have launched
in the manufacture of IMA pages

Why are the AMP pages fast?

The AMP project is based on 3 new elements, which combined produce performance gains.
● The HTML amp first;
● The Javascrip AMP library;
● And the DSM AMP.


The HTML AMP is a web page description language based on a reduced HTML 5 tags. If you know HTML 5, you will not have to learn a new language to encode IMA pages. Instead, we will have to learn the list of authorized tags in HTML AMP, the reference of which is here:

The narrow tags set allows both to drastically lighten the code, but also to ban tags that are slow to interpret by a browser.

The HTML AMP is defined as a subset (“subset”) of HTML 5, so it is HTML 5, and the AMP code is understood natively by all browsers supporting HTML 5.

Fig .2. Minimum code of one page in HTML AMP


The Library Javascript javascript


The Javascript code is often the source of the slow-display problems of the mobile pages. This code is often cumbersome, complex and slow to execute. Paradoxically, the mode of «responsive» pages further strengthened the problem.

With the AMP pages, the rule is to prohibit any Javascript code on the page, except for the call to an optimized library: JS AMP. This library contains functions that optimize the page display.



Google provides a special Delivery Network, based on its infrastructure. This CDN is a worldwide network of “proxy-cache” servers that keep a cached version of your AMP pages to speed up their display.

The systematic use of a cache with a heavy meaning: if your pages need to be regenerated with each HTTP request, then convert them into AMP pages, because the whole framework assumes that you can work on a static version of the page.

Magic behind the pages AMP

The combination of the three components of the AMP architecture allows for cascading optimization. JS library in particular makes it possible to achieve the «lazy loading»: only the code corresponding to “visible” content on the screen is loaded. Some content is then stacked to speed up the display of the following screens.

The package produces pages that display almost instantly. You can test the operation on Google’s result pages, by going to this URL from a mobile:

Fig .4. Presentation of the AMP architecture at the
Launch press conference on 7 Oct 2015

What differences between Google’s project and the “instant articles” of Facebook?

Google’s strategy is from the start of Facebook: Google launches a doubly open format:
・ This is an open source project, open to contributions from other partners, and launched in partnership from the start with heavy vehicles like Twitter, WordPress or Linkedin. And this project can evolve towards much broader needs than the original perimeter (the news sites).
・ The AMP project is not linked to a closed platform: only the CDN dedicated to the AMP pages is a “Google property” and its use is free. For the rest, creating AMP pages does not create dependency with a particular platform. There is no income sharing system.

In contrast, the Facebook project, faithful to its usual strategy, is limited to its sole owner platform: the “moment articles” are pages served by the Facebook application. And advertising revenues are shared between Facebook and publishers.
Technically, projects are also quite different. And these differences oblige the webmaster who wants the best of three worlds to:
・ Generate “normal” mobile pages;
・ Provide a stream formatted for the instant articles on Facebook;
・ And generate a new version of mobile pages, AMP standards for Google and Twitter.

How do I create an AMP version of my content?

Creating a AMP version of its pages already involves modifying its “normal” pages, adding to any page with a AMP version, a “rel = amphtml” tag pointing to the equivalent AMP version. The AMP version must contain a “rel = canonical” tag to the normal version of the same page.

Then, of course, an HTML version of the same content must be generated. With some CMS, this may be relatively simple. For WordPress, a plugin already exists (see URL at end of article), which automatically generates an HTML AMP version of any page generated by CMS. For other CMS, this means creating additional page templates that generate an AMP-compatible code for the same content.

But for some complex software architectures, creating an existing AMP version of existing pages may not be trivial.

Fig .5. An illustration from a presentation by Distilled showing the role of rel beacons =’ amphtml’and rel =’ canonical’to link the normal pages and their amphtml version


Pages AMP: is this a duplicate content source?


In theory, the AMP pages are pages whose content is a “duplication” of the content of the “normal” page. In practice, Google solves the problem using traditional solutions:
・ A < link rel =’ amphtml’tag in the normal page direction to the AMP version;
● And a tag < link rel =’ canonical ‘ > pointing to the normal page from the AMP page in the other direction.

These two tags, properly implemented, allow Google to understand perfectly how to exploit the two versions of the page without confusing the two versions of these pages with duplicates. As far as Google is concerned, the existence of this new source of duplicated content is therefore no problem, and no side effects are expected.

On the other hand, competing search engines did not announce that they associated themselves with this project, where even they would support this new page format, so some surprises are possible with Bing, Yandex or Baidu for example. We do not yet have enough to find out if this is a real problem, but in the case of an international site, some tests will be essential before inconsidérée into the’all AMP’for its mobile pages.

In addition, problems may arise if the rel tags = amphtml, or rel = canonical, are poorly implemented. The greatest vigilance is required during the deployment. It is therefore necessary to verify that the tags are present, and that they do not contain any code error or bad value at the destination URL level.

Is the publication of IMA pages will improve my rankings?


Contrary to what has been noted here and there on the net, Google has not officially confirmed that there would be a boost in its classification algorithm for the AMP pages. In fact their communication on this has changed, and it does not seem that a clear decision has been taken. At the launch in October, such stimulation was not mentioned in the communication. At the press conference on 9 December, the possibility of stimulus was raised this time. But without making it clear whether this boost was directly linked to the AMP pages, or to the desire to promote fast pages in general, in context of mobile use. And since then, this «boost boost» has not been written in writing.

At the San Francisco press conference, the presence of a fast label for the AMP pages was announced. The presence of such a label in the mobile result pages alone may prompt users to click on these fast pages.

But above all, Google showed at the launch press conference in October a display of its pages results with a carousel at the top of the page reserved for fast pages (so not only the AMP pages in theory, but in practice… the future will tell us). If such a carousel is really present in future pages of results, the visibility of visibility will become clearly impressive.


Is it necessary to start now in the creation of AMP pages?

At the time of writing this article, the project is still in experimental phase. Regularly, the specifications around ampHTML evolve. This can therefore deter some of us from engaging in major projects. Until the end of February, the visibility of the AMP pages will remain confidential.

Fig .7. Twitter should be the first to display AMP pages on its site.

The first site that will actually exploit them will be Twitter, which will highlight the AMP content early in February. For Google, no traffic will be sent to the AMP pages until the end of February 2016. Only on this date will the urls of AMP pages begin to appear in Google’s results pages.

On the other hand, the project seems to be particularly relevant today for editorial sites, news sites, or for certain forms of “native ads” advertising formats.

In view of these elements, one might be tempted to ignore this project until it is more complete. The problem is that the adoption of this new format may be particularly rapid. First because of the activism of its sponsors (Google and Twitter, and many partners), but also because the AMP pages are the first effective response to problems posed by the slow display of mobile pages.

It seems appropriate to test this new format now, and start thinking about how best to implement the AMP pages on your sites. Despite their relative technical simplicity, creating AMP pages may be more complex than expected for certain software architectures. To think quickly about the solutions to produce them is therefore to show foresight.

And tomorrow? What future for the AMP pages?

Creating an “accelerated” version for its mobile pages is creating a new version of its pages, and this runs counter to the heavy trend that always leads to the adoption of universal solutions.

The AMP pages are not currently adapted for any type of content, and any type of site. It can therefore be predicted that the AMP project will evolve considerably over time to “embrace” a larger number of cases of use or will be superseded by new initiatives more “universal” to make the mobile pages faster to display…

What approach will prevail? That proposed by Apple or Facebook? It is difficult to believe it because these are’closed’projects. That supported by Google and Twitter? Another project? The future will tell us. But the next few months are likely to be very rich on the subject of accelerating mobile pages.

Useful links for Google AMP

The AMP project site

The reference HTML HTML

Repository on GitHub

The Démonstation site of Google

The site of the “moment articles” project of Facebook:

Blog ticket announcing the AMP project