Should I implement Accelerated Mobile Pages (AMP)?

 

What is AMP?

Accelerated Mobile Pages (AMP) use stripped down code (AMP HTML) to load content more quickly than regular web pages.

The AMP Project is backed by Google but is open source (unlike Facebook Instant Articles or Apple News which are closed projects, meaning that the technology is only used on their respective platforms), with partners including WordPress.com, Adobe Analytics, Pinterest, LinkedIn and most recently Twitter serving Accelerated Mobile Pages to users. Pinterest’s Jon Parise claimed that its AMP pages load four times faster and use eight times less data than regular mobile optimised pages – so there’s a benefit even for image-heavy websites.

iphone 1.gif
 
iphone 2.gif

What are the benefits of AMP?

Google has stated that the use of Accelerated Mobile Pages is not a ranking factor, which feels like one of Google’s “technically true” claims. Site speed is a ranking factor and passing the mobile-friendly test is effectively a requirement of ranking well on mobile – implementing AMP ticks both of these boxes, potentially improving a page’s search visibility.

donald trump.jpg

FEATURED IN THE CAROUSEL

Sites featured in Google Newsstand are set to gain even more through AMP implementation as Accelerated Mobile Pages may be featured in the carousel at the top of some mobile search results.

The thumbnails are suitably large (plus they’re the only images in mobile search results) so click through rates (CTR) tend to be high, but getting featured in the first place can be difficult.

IMPROVED CLICKTHROUGH RATE

Accelerated Mobile Pages in Google’s search results are labelled with a lightning bolt icon, which can result in an improved clickthrough rate as searchers become more familiar with the technology.

IMPROVED PAGE-LOAD SPEED

In a July 2016 Think with Google post, the search engine claimed it had built a machine-learning model that could predict mobile bounce rates by looking at 93 different page metrics to 96% accuracy. Page load speed featured prominently, with optimisations to the number of page elements and the size and number of images on a page contributing disproportionately to load times.

Whether Accelerated Mobile Pages benefit from higher conversion rates depends on the implementation: stripping out page elements can reduce the overall customer experience and reduce conversion rates (which is one of the reasons we’d advise against using a plugin to convert pages – more on that later). However, sites with far above average page load times may not be able to keep a visitor long enough to convert them anyway.

What makes AMP so fast?

Speaking at Search Engine Journal (SEJ) Summit in June 2016, Google’s Gary Illyes claimed that the median load time for Accelerated Mobile Pages was less than 1 second, versus a 20 second median page load time for sites using responsive design.

The quickest load times are experienced when pages are using the AMP Cache: literally an index of cached, validated Accelerated Mobile Pages published to the web. AdWords and other Google products use the cache to serve pages in a second – it’s unlikely that these speeds will be achieved without the use of the cache.

As to whether businesses should make use of the cache, one of the biggest challenges is the differing URLs between the AMP URLs (which begin with some form of https://www.google.com/amp/) and the actual (canonical) address of the page on the business’ domain. Recently Google has added a button displaying the canonical URL (and allowing users to visit the business’ website, which otherwise would not be possible), but sharing and linking can still be a challenge – and for visitors it can feel as though they’ve never left the search engine at all.

This is less problematic for PPC landing pages, but extremely fast load times can be achieved without the use of the cache so we generally wouldn’t use it.

How fast should my website load?

A webpage should load in less than 3 seconds. A Google study from 2016 found that 53% of visits are likely to be abandoned if pages take longer than 3 seconds to load, with half the people surveyed stating they expect a page to be displayed in less than 2 seconds.

AMP Project tech lead Malte Ubl listed optimisations required in AMP based documents, pointing out that every web page can have these optimisations, but AMP pages cannot not have them.

Google already provides a tool called PageSpeed Insights that audits a page for potential improvements to reduce page load times. It’s entirely possible for pages to load within 2-3 seconds without implementing AMP. Some of the more significant optimisations Ubl lists include:

  • Lazy loading (objects aren’t loaded until they’re needed e.g. a visitor scrolls down far enough to see further text – for an example of lazy loading in action, check out the blog we built for Paddy Power
     
  • Extra points for prefetching lazy loaded resources (just don’t load them at the same time as everything else)
     
  • Prerender everything – this improves crawlability for Google (which does not play well with JavaScript) but also means that pages are often ready for users by the time they are navigated to, allowing them to load almost instantly (AMP pages are so lightweight it’s extremely “cheap” to prerender them)
     
  • Use inline stylesheets (removing some HTTP requests from the critical rendering path)
     
  • Load JavaScript files asynchronously

Many of Ubl’s optimisations are highlighted by PageSpeed Insights. Some aren’t. The Content Delivery Network (CDN) available to AMP users is the aforementioned cache, so it’s important to know that less intrusive CDNs are available (and awesome).

amp 5.png

It’s tempting to obsess over the scores displayed by PageSpeed Insights but remember, a 100/100 score doesn’t mean your page is loading as fast as possible. The score is calculated based on a checklist, and both a 1KB and 1MB page can theoretically achieve a 100 score. We use GTmetrix to audit page speed and they’ve written a great post about why their results differ to other tools.

Tracking with Google Analytics

Google is continually improving its support for AMP in Google Analytics, rolling out enhancements in May 2017 to bring tracking of AMP pages in line with non-AMP pages. In September this was further enhanced to cover tracking of AMP pages served from the Google cache, so analytics users can now understand whether a visitor to a non-AMP page or an AMP page served by their own domain has ever visited an AMP page served by Google (through AdWords, for example). This works via an API called Google AMP Client ID API and Google Analytics, so for now it does require opt-in via a code change.

Google has also highlighted that user and session metrics are likely to fall following an opt-in as “formerly distinct users are recognised as the same person” – which in turn will improve the accuracy of related metrics such as Time on Site and Bounce Rate. We’d strongly recommend implementing AMP Client ID API for this reason. Currently reported sessions may not reflect actual traffic levels for websites using Accelerated Mobile Pages, so remember to add an annotation in GA when making the switch.

How do I implement?

There’s a tutorial here, but broadly the requirements are as follows:

 Rule

 Description

  Start with the <!doctype html> doctype.

  Standard for HTML.

  Contain a top-level <html ⚡ >tag
  (<html amp> is accepted as well).

  Identifies the page as AMP content.

  Contain <head> and <body> tags.

  Optional in HTML but not in AMP.

  Contain a <meta charset="utf-8"> tag    as the first child of their <head> tag.

  Identifies the encoding for the page.

  Contain a <script async   src="https://cdn.ampproject.org/v0.js">   </script> tag as the second child of    their <head> tag.

  Includes and loads the AMP JS library.

  Contain a <link rel="canonical"   href="$SOME_URL"> tag inside their   <head>.

  Points to the regular HTML version of     the AMP HTML document or to itself if    no such HTML version exists. This is     similar to howm. mobile sites use   canonicalisation.

  Contain a <meta name="viewport"   content="width=device-width,minimum-   scale=1"> tag inside their <head> tag.     It's also recommended to include   initial-scale=1.

  Specifies a responsive viewport.

  Contain the AMP boilerplate code in   their <head>tag.

  CSS boilerplate to initially hide the     content until AMP JS is loaded .

 You do not need to use a particular CMS to be able to implement Accelerated Mobile Pages.
 

Should I use a plugin to convert pages to AMP?

There are several plugins available in WordPress that automatically covert pages into multiple mobile formats including AMP and Facebook Instant Articles: PageFrog is among the best known; Yoast SEO also has this ability; but the AMP plugin by WordPress-makers Automattic is as close as it gets to being official (that said, it’s received pretty mixed reviews). There are also plugins available for Drupal, Magento and others.

Each plugin does a reasonable job, but users rescind some control over design elements and are left at the mercy of the developers for updates (Automattic’s AMP plugin can go months without a new version, which isn’t ideal for a framework that’s updated so frequently). Upgrading to the latest version of WordPress can also sometimes break the plugins, making for another potential dev headache – or overnight loss of search visibility if it isn’t fixed quickly.

The ampproject.org website exclusively uses AMP HTML, so it’s a great example of the experience that can be delivered through pages built using the AMP framework. The Automattic plugin, by comparison, doesn’t give any customisation options – just add /amp/ to the URL of any of your pages to see its AMP version and you’ll get what you’re given – so custom-built pages are pretty much essential for businesses keen to preserve their user experience through implementation of AMP.

However, we wouldn’t recommend plugins as a long term solution.


Should I implement AMP on my site?

It’s not for everyone, but it is for publishers (especially those already featured in Google News). As most of the current benefits of AMP can be gained by optimising site speed, our recommendation on whether or not to take the plunge usually relies on exhausting most other site speed optimisations.

 
Stephen Kenwright