Accelerated Mobile Pages — What Are They and How Do I Implement Them?

Accelerated Mobile Pages — What Are They and How Do I Implement Them?

We are living in a world with ever-improving internet speeds, meaning every day more and more people can access the vast array of information on the web as we push to bring it to the next billion. Whether or not this is a good thing when it comes to site content, however, is a different story.

Ever increasing speeds allow for a site to include ads, analytic scripts, information interstitials and more. These can all accumulate rapidly and while each may not have a significant impact on user experience by themselves, they can add up to a much slower load time regardless of internet speed. Not only does this have a negative effect on the UX but it can also significantly increase your bounce rate. It is known that up to 40% of users may navigate away from a page if it has not loaded within 3 seconds — this in itself can cause an impact on your business as users navigating away means less traffic, and when coupled with those users who turn to ad-blockers to aid in loading times, you may see your revenue slashed.


What is AMP?
Getting Started With AMP
Validate Your Page
What Next?

What is AMP?^

2016-06-06Obviously, web developers are not in the habit of slowing down websites on purpose, the code that ultimately slows down a site is implemented in an attempt to increase monetization allowing for more content to be produced. This balance between UX and monetization is becoming an ever more important decision as the “free ad-supported internet” is slowing fading; many sites are now seeking alternate monetization methods, such as which blocks traffic if it detects ad blocking or The Wall Street Journal that hides content behind a paywall. That is where the fully open source AMP project enters, by speeding up the loading process and removing much of the unnecessary content of a page it aims for a significantly improved experience that in turn could lead to users adding your site to an adblock whitelist and a much lower bounce and abandonment rate, many sites will even appear to load almost instantly as can be seen in the real time gif on the right.

The AMP Project set out with a set of goals for fixing many of the problems web developers face each day, these are: pages need to be fast, these pages need to be validatable and, the new solution needed to be easy to implement. There had to be strong incentives to actually make the switch and finally it had to merge with the open web (free and ad-supported) not replace it. These lead to the creation of AMP, a method of developing fast mobile pages.

Put simply AMPs are just normal HTML pages, with a few guidelines stating what you should and should not include. This means that the time taken to make your site AMP-ready is greatly reduced compared to other options such as building a custom app. For pages that do not use custom javascript and static content you likely do not need to create an alternate page for AMP and can just modify your current HTML. Each AMP contains:

<script async src=“”></script> 

This javascript library adds to your markup allowing the load chain to be prioritised meaning 3rd party content, that is less likely to be relevant to the consumption of the content, to be loaded later after the main elements. This results in the users of your site being able to begin consuming your content as soon as they arrive without having to wait for critical information to display. All aspect ratio properties have to defined in advance meaning the js “knows” exactly how the page should display before content is loaded, in turn stopping the common issue of a page “jumping” around as more elements load above your viewing area.

This by no means causes AMP to be faster than hand-tuned sites, but they will still be faster than the average mobile site. This is an important clarification because one of the first guidelines for AMP is that the can only be valid if the do not contain things that may be slow. Whereas by hand-tuning your site you may still be able to include these things and still have your site load quickly, that is a decision each web developer will need to make on an individual basis.

There are quite a few more optimizations/requirements that define AMP  including:

  • “All external scripts must be async” meaning if your site has a script tag without an async attribute then it is not valid a AMP document.
  • “Resources must have static sizing”, that is not to say content such as images must be fixed sizes, it does mean though that the size of resources can be determined before they are downloaded. This leads to the page jumping fix mentioned earlier.
  •  “Extended component downloads cannot block the page layout” Extended components require the use of additional elements, these can be viewed below in the Getting Started With AMP section and allow just one HTTP request to layout the full document.
  • “Third party javascript can only be displayed in sandbox iframes” The benefits of this being that sync scripts do not block the rendering of the main page and the document.write-ing of additional scripts by them doesn’t lead to slower rendering.
  • “All CSS must be in-line and no larger than 50 kilobytes” 50Kb is ample for a complex page but not for the entire site. This is potentially the single most important performance improvement in AMP.
  • “There must be no HTTP requests until fonts start downloading” which is why the following exists in AMP even though at first glance it appears horrific, this stops flashes of unstyled content (FOUC).

  • “Style recalculations must remain minimal” AMP will only trigger 2 style recalculations during the loading of a page, it already knows when things resize which ensures the need to measure are kept to a minimum.
  • “Animations must be GPU-optimizable” AMP allows animations and transitions but only transform and opacity ensuring that the GPU can run them, again ensuring speed.
  • “Resources must be prioritized” AMP controls the resource downloads and optimises them around the user. Resources that are likely to be visible to the user immediately (known as the 1st viewport) are given a higher download priority than those at the bottom of the page, likewise, ads are downloaded with a lower priority and when the user is idle. It is the current goal of the tech lead of the AMP Project that AMP pages will eventually load faster with no adblocker than with one. This is not an unrealistic goal as adblockers slow loading by scanning the document object model whereas with AMP the ads are downloaded after the rest of the content into predefined spaces and ads such as full-page overlays are not allowed at all in AMP.
  • “Instant loading via intelligent prerendering” normal browser prerendering can use significant CPU due in part to the potential for the execution of arbitrary javascript on the prerendered page and because it typically downloads all the resources on that page. AMP, however, will only load the aforementioned first viewport and no 3rd party javascript. Content such as iframes are all left until the user enters the page to be downloaded. This means that while it appears that the page is fully downloaded it is actually only the first viewpoint which is sufficient to appear instant in most use cases.

These come together to form fast loading clean looking pages such as these:

Image 065Image 057 Image 058

Most XDA portal content is AMP-compatible

Getting Started With AMP^

A basic Hello World! AMP document would look like this which will display a simple html page, but that’s it.

If you would like to start developing your first AMP document the template below can be used to get yourself started, as usual with web pages, this document should be saved with the .HTML file extension.

Whilst the vast majority of HTML tags can be used without issue in AMP, some tags are replaced with new tags allowing for the setting of the page layout. The most commonly used tags that are different in AMP are: amp-iframe, amp-img, amp-anim, amp-audio and amp-video. All of these are used the same as their non-AMP counterparts, for example:

One consequence of using the amp-iframe tag is that it cannot be placed in the first 600 pixels or 75% of the 1st viewport from the top of the page.

In order to modify the presentation and style of a page you can use common CSS properties, however, it is worth noting that as mentioned above each AMP can only have a single stylesheet (no referencing external stylesheets) and to ensure the rapid loading of these pages all pages must have a set size from the beginning. The following styles are not allowed.

Banned StyleDescription
InLine Style AttibutesAll styles must be defined in the <head> of the page, within a <style amp-custom> tag.
! important qualifierUsage is not allowed. This is a necessary requirement to enable AMP to enforce its element sizing rules.
<link rel=”stylesheet”>Disallowed with the exception of custom fonts.
* (universal selector)Negative performance implications and could be used to cirvumvent other selector restrictions.
:not()Could be used to simulate the universal selector.
Pseudo-selectors, Pseudo-classes, and pseudo-elementsPseudo-selectors, pseudo-classes and pseudo-elements are only allowed in selectors that contain tag names and those tag names must not start with amp-. Example OK: a:hover, div:last-of-type Example not OK: amp-img:hover, amp-img:last-of-type.
-amp- calss and i-amp- tag namesClass names, in author stylesheets, may not start with the string -amp-. These are reserved for internal use by the AMP runtime. It follows, that the user’s stylesheet may not reference CSS selectors for -amp- classes and i-amp tags.
behaviour , – moz-bindingThese properties are not allowed for security reasons.
filterBlacklisted due to performance concerns.
Source: The Accelerated Mobile Pages Project

Validate Your Page^

You may decide that you would like both AMP and non-AMP versions of the same site in order to utilize the resources not allowed in the former. In this case, you will have to include <link> to the <head> in order to allow services to differentiate between the two, this allows for browsers and other services to detect the AMP version of your page and display it if appropriate.
To the non-AMP  add: <link rel=”amphtml” href=”URL/amp.html”>
and to the AMP page add: <link rel=”canonical” href=”URL/desktop.html”>

Testing and validating your page is simple: to test you can simply save the page as you would any other HTML site. You can then open it your browser or in a local web server. To ensure that the page is valid you will have to open the page in your browser after adding “#development=1” to the URL


Finally, open the Chrome DevTools Console which will display any validation errors. The AMP validation service allows for the discovery of your new site by third parties such as the Chrome carousel and other websites.


What Next?^

By now you are well on your way to creating full AMP documents, but the learning does not end here. Google offer several Codelabs, full hands-on coding tutorials which you find here:

Accelerated Mobile Pages Foundations,
Accelerated Mobile Pages Advanced Concepts

If you are using Chrome’s desktop browser but would like to view AMP instead then this desktop Chrome extension allows you to make the switch at any time as long as the page allows it.

The AMP Project is continually developing and this year’s I/O was no different, catch up on the latest developments here.

Grab the AMP source over at Github
Do you prefer AMP sites? What would you like to see changed? Leave a comment below!

About author

Mathew Bloomer
Mathew Bloomer

He fell in love with Android after buying a T-mobile G1 in 2008 and hasn't looked back since. He firmly believes the future of technology lies within bio-hacking and is an NFC implantee.