What is AMP?

The Accelerated Mobile Pages project is an open source project developed and sponsored by Google. The goal of the project is to improve how quickly web pages load on all devices. Google says it wants the user experience to be nearly instantaneous when accessing sites on mobile devices.

AMP creates a faster experience in 2 ways. First, it removes and restricts large swathes of functionality used by modern sites to create a faster, more streamlined experience. Second, it enforces the use of certain newer technology and standards, such as HTTP/2 and GPU-acceleration, to ensure a page that loads and renders quickly. You can see an example of an AMP web page, loaded on a mobile device, in the screen shot below:


You can also try AMP pages directly on a mobile device right now. First, access this article on a mobile device (or adjust your browser’s viewport size and user agent settings to simulate a mobile device). Then, go to this demo Google search link. You will see the “Top Stories” section now features a carousel of stories that match the search term and are published using AMP.

Why was AMP created?

AMP was created to solve the problem of users clicking or tapping away from sites whose pages take too long to load. Mobile users tend to want more instant gratification than do desktop users. An increase in page load time tends to make a website’s “bounce rate” go up. That’s bad for publishers and it’s bad for advertisers, neither of which make any money when users give up on seeing their content.

More practically, Google is trying to compete with Facebook’s Instant Articles. Because Facebook is a “walled garden”, it doesn’t allow outside companies to benefit from its proprietary approaches to publishing. Google, being an outside company, seeks to create its own mobile page load performance solution for the open Internet.

How does AMP work?

From the user’s perspective, Google search results reveal AMP-enabled sites in the top stories carousel of mobile search results. They load fast on almost every speed of connection. Because AMP pages are pre-rendered and stored on Google’s caching servers, they load faster on slower connections than traditional HTML mobile sites. From a developer’s perspective, the AMP spec determines a limited set of technical functionality. Essentially, this strips the HTML spec down to its bare bones elements, and then rebuilds it in the image Google deems most performant for today’s mobile content.

Another feature of AMP is that it uses cloud caching to move content closer to users. This is certainly not unique or novel in the world of content hosting; Content Delivery Networks (CDNs) like Fastly, Akamai, and Instart Logic have been competing in this space for several years. AMP leverages Google’s own CDN system.

The AMP technology stack consists of AMP HTML, AMP JavaScript, and the Google AMP Cache, all of which are developed in an open source manner. Anyone can contribute and use it in any way they see fit, with certain restrictions put in place to ensure the integrity of the system.

AMP HTML is a subset of HTML made up of specially-named tags that load the basics of HTML in a more efficient manner. It imposes a few restrictions on regular HTML. However, it doesn’t necessitate the creation of new rendering engines. AMP HTML will load in all the major browsers.

AMP HTML documents are uploaded just like HTML documents and live in the document root of the web server along with all the other HTML files.The web server doesn’t need any special tweaks or configurations to deal with it.

The secret sauce here is the proxy serving system that applies transformations to the AMP HTML documents before serving them to the client. Some of the transformations include making inline images visible above the fold, preloading components, and minifying HTML and CSS.

With AMP HTML, you can use custom styling through CSS without restrictions. What you can’t do is implement custom Javascript.

AMP JS manages all the resource loading for your documents. Because it is optimized specifically to the AMP spec, Google has disallowed further javascript written by the developer.

The reason for such a heavy-handed JS approach is that synchronous JS can block rendering during page load. AMP JS is asynchronous.

The third component of AMP is the AMP cache, which also includes a way to test or validate the caching mechanism. The caching fetches, caches, and improves the performance of all AMP HTML pages. All documents, JS, and images load from the same HTTP 2.0 origin. The validation system runs a set of assertions and makes sure that the page will work and that it doesn’t have outside dependencies.

Example of AMP page

An AMP age looks much like a regular HTML page, with a few exceptions.

<!doctype html>
<html amp lang="en">
   <meta charset="utf-8">
   <title>Rigor.com AMP example</title>
   <link rel="canonical" href="http://example.rigor.com/article-metadata.html" />
   <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
   <script type="application/ld+json">
       "@context": "http://schema.org",
       "@type": "MyArticle",
       "headline": "An article using AMP for publishing content",
       "datePublished": "2016-03-02T03:00:00Z",
       "image": [
   <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
   <script async src="https://cdn.ampproject.org/v0.js"></script>
   <h1>First page on the mobile web</h1>


As you can see, it contains a <!doctype html> and <html> tag, but with the amp attribute to differentiate it from HTML5. There are <head> and <body> tags, a <link rel=“canonical”> pointing to the normal HTML version of the page (or to itself if this is the only version), and <meta> tags specifying character set and viewport.

Where it begins to differ significantly is with the <script> tag which calls to the AMP JS library loaded from the AMP CDN as the last element in the head.

Also contained in the head is the <style amp-boilerplate> AMP boilerplate style tag. The purpose of this tag is to reset the page to the specifications required by AMP for simplifying the page for pre-rendering.

To add an image to your page, you use the <amp-img> tag set, like this:

<amp-img src=“header-image.jpg” alt=“Article header image” height=“400” width=“800”></amp-img>

If you need to include an iframe for an ad, you cannot use the <iframe> tag specified in traditional HTML. You’ll instead need to implement the <amp-iframe> tag set. But before you add that tag, you must include a <script> tag to asynchronously call the extended code for this custom element from the CDN.

<script async custom-element=“amp-iframe” src=“https://cdn.ampproject.org/v0/amp-iframe-0.1.js”></script>And now you can call the <amp-iframe> tag like this.

<amp-iframe width=300 height=300
   sandbox="allow-scripts allow-same-origin allow-popups allow-popups-to-escape-sandbox"

If you want to skip over using “legacy” iframe tags, then jump straight into using AMP’s ad tags.

<amp-ad width="300"

More examples of different types of ad insertion via AMP are found at AMP by Example.

Example of validation

AMP is a strict specification. As you develop AMP pages, you’ll need a way to validate the AMP syntax to ensure that it won’t produce errors. Fortunately, AMP includes a validator as part of the AMP JS library. All you need to do is:

  1. Open your page in a browser
  2. Add #development=1 to the end of the URL of the page
  3. Open the browser’s dev console. This, of course, works best within Chrome.

If your page isn’t valid, you’ll see lots of red in the console stack of error messages. Address these errors like you would in a typical debugger by locating the line (or general area) that is generating the error, reading the error message, and referring to the link to the AMP spec that describes the nature of the error. Fix the error and re-run the page. Repeat until the error messages all disappear.

It is very important that you fix errors using the validator before considering your AMP page “done”. Twitter, Google, et. al. will not integrate your content into their pages and search results until you do so. Your page won’t even make it into the AMP cache until all the errors are removed.

Waterfall Analysis

Have a look at this MSNBC article with AMP on iPhone 6….

analysis msnbc amp site

AMP enabled msnbc waterfall

This page took a total of only 951ms to get to the onload event. It only had to do 33 requests. The number of requests would even be fewer if the amp_preconnect_polyfill item were eliminated.

Now, consider this Rigor Waterfall Report of the same MSNBC article without AMP on Chrome. Notice how the load time is about 7 times longer than with AMP. It took a total of 7.25 seconds to get to the onload event and had to do 248 requests. That’s a significant difference for mobile users who just want to read the article.

analysis msnbc no amp site

MSNBC article no AMP

Positive Impacts of AMP

AMP is open source. That means you are free to use and contribute to the AMP spec without additional direct fees or costs from Google. You don’t need to buy a subscription to anything to write AMP HTML, reference AMP JS, or use AMP caching.

Companies can build their own caching systems. If they feel that their needs would be better served by doing so, any company can do this. There is probably little reason to write your own caching system unless you have a very, very specific need that cannot be met by the AMP caching system.

The more people use it, the faster it gets and more available it becomes. As with any new technology, early adoption drives a more robust adoption cycle. There will be positive feedback loops resulting in more adoption and more features as the spec comes into wider use.

AMP pages now appear at the top of Google’s mobile search results. The system is “ready to go” as-is and as soon as Google crawls your new AMP site, you’ll start appearing in the Google Top Stories carousel at the top of mobile search results.

Paywalls are supported. AMP pages do support several video players as well as paywalls, sponsored content, and “walled garden”-type sites.

Negative Impacts of AMP

You might lose SEO rank if you’re not ready to use AMP. Because Google is prioritizing sites that use AMP in its search results, even when it claims that AMP is just one of many ranking signals, be prepared to lose ground in your SEO ranking unless you provide AMP-based content.

Domain authority may suffer. If a reader tries to share your AMP content link from Google’s mobile search results, the link will point to Google’s servers, not your own domain. There is currently no way to have your AMP content hosted on your own servers and still appear in Google’s prioritized search listings. Your content must be hosted on Google’s AMP caching servers.

You need to decide whether to fork your content or start from scratch. You create an alternate version of your site that conforms to AMP, or you start developing your site in AMP from the ground up. If you develop a separate version of the site, then you need to also publish it on its own unique URL. WordPress users can install a plugin to handle this for them.

Budgets will need to be retooled. Content and site development budgets today are geared toward only creating a single version of content. Adding AMP to the mix will necessarily create more development overhead. Content development shops that are not significantly agile will struggle with forking their content layouts in two different directions.

Google’s plans are unclear for force-caching your regular HTML sites. The question has to be asked whether Google eventually plans to create AMP cached versions of regular HTML sites whether site owners are aware or not.

Your sites will be a bit drab for a while. Because the AMP spec determines a limited set of technical functionality, AMP-based pages will necessarily be barebones until more sophisticated layout and design capabilities are added to AMP.

All your carefully-crafted Javascript is now useless. Mostly. Javascript is mostly forbidden on AMP sites because outside JS conflicts with the purpose of AMP JS, which is to lighten the page load time. There is an <amp-iframe> tag that replaces HTML’s <iframe> tag and allows custom Javascripts to load, but with the restriction that you won’t have access to data within your script running in <amp-iframe> as you would with the traditional <iframe> tag.

What are Rigor’s thoughts?

At first glance, we think this is an effort to solve the issue of engineering bloat with more engineering bloat. Publishers should first apply mobile Web best practices and optimize pages conventionally rather than leveraging a special HTML-subset like AMP for building great mobile UX.

It is not yet clear how AMP differs significantly from other freemium CDNs other than having its own HTML tags and JS and being open source. Therefore, a continued emphasis on optimized pages and use of other CDNs is likely to result in an acceptable performance profile when compared to AMP.

AMP asks developers to add a layer of new tags to W3C standards when the W3C standards have been around for decades. Vendor divergence from W3C standards has given us problems like the Internet Explorer browser and other user agents not agreeing when it comes to rendering the output of HTML code.

Analytics will likely experience integration issues as AMP initially rolls out. Google has a special cadre of analytics partners it says it supports, but the jury is still out as to how well those platforms support AMP in daily reporting scenarios, especially custom ones.

Google admits that it cannot guarantee that all vendor technology will work well inside of AMP. If ad and analytics vendors have issues with AMP, Google offers little more than a contact form for vendors to report the problem and a possible solution. It may be too early to make the move to AMP.

Ultimately, AMP is something authored and, ostensibly, controlled to a degree by Google even if it is open source. Even though Google emphatically states that AMP is truly open source, it still feels proprietary when considering the example of JS being blocked out. That is, except in cases where a special analytics tag, loaded from a file on Google’s own servers only, is sent to Google partners and big-brand analytics outfits like Outbrain, AOL, OpenX, comScore, Adobe Analytics, Parse.ly, Chartbeat, Nielsen, ClickTale and, of course, Google’s own DoubleClick, AdSense, and Analytics. Google screens analytics servers for aspects of privacy, security, and performance, so not everyone can “play” until they meet Google criteria.

Admittedly, all of that partnering and closure offers more stability, security, and privacy. If you’re willing to trade away openness for speed and proprietary, closed systems, then AMP is a good compromise.

Interested in improving your website’s performance with optimizations like AMP? Then you’ll love Rigor’s performance monitoring and analysis platform. Rigor tests your entire website and identifies over 420 performance defects that are slowing it down. Our continuous monitoring provides 24/7 performance visibility of your website’s performance and availability, and allows you to understand exactly what you can do to make it faster.