site logoTune The Web
I've written a book! - click here to view or buy "HTTP/2 in Action" from Manning. Use code 39pollard to get 39% off!

OPINION - Implementing Accelerated Mobile Pages (AMP)

Category:
  1. Blog

This page was originally created on and last edited on .

Introduction

The AMP Project aims to drastically improve the web experience for mobile users. It's backed by some pretty big names including Google, Twitter, WordPress and a whole raft of publishers listed at the bottom of the AMP Project home page, which reads like a virtual who's who of the online publishing world.

If you've read my previous blog post questioning the need for AMP then you'll probably have gathered that I was not initially a big fan, for a number of reasons. The project aims to enforce a restricted version of web technologies to meet the "AMP standard", which will basically not allow you to create a slow page. Now there is no doubt a lot of sites could do with the stick approach, since the carrot of good performance and the benefits it brings, has not given sufficient reason for website owners to make sure their sites are fast. Web site owners too often overload their website with needless javascript, countless ads, and other items that result in poorly performing websites. So if AMP can solve this, then I'm all for this.

However my main issue with AMP is that if you're that interested in your website performance then you can make it faster as easily as you can implement AMP using the same techniques it uses - there's no need to implement this as a separate "standard".

Anyway it turns out the Internet has not had a massive about-turn based on my little blog post, and the AMP project is continuing on with full steam. Google have started sending traffic to AMP pages since February 2016 through the the Top Stories carousel - though only for some countries at the time of writing. The SEO world is abuzz with what opportunities this will give to sites that embrace AMP, and whether sites that don't will be left behind.

So, despite my reservations on the concept, I thought it was worth investigating what would be involved in creating AMP versions of this websites's posts and whether some hands on use would address or prove my concerns. Due to the fairly new nature of the AMP project, and the fact things are changing on that daily, I've decided to keep this post under the Blog section of the site, rather than as a Performance guide, as it's primarily opinion based for now.

What's involved in creating an AMP page?

An AMP page is simply a regular HTML, page with a few extra rules and restrictions:

Once you think you have an amp page you can look at it in Chrome with developer tools open and looking at the console, then add "#development=1" to the URL to validate it. For this blog I've made AMP versions of the pages available by adding "/amp/" to the URL, so you see the AMP version of this page at: https://www.tunetheweb.com/blog/implementing-accelerated-mobile-pages/amp/ (Update July 2017 - I have decided to remove AMP from this site.

You can validate the AMP version of this page by opening the following link while viewing the Console in Chrome Developer Tools (F12): https://www.tunetheweb.com/blog/implementing-accelerated-mobile-pages/amp/#development=1

All going well you should see something like this in the console:

Successful AMP Validation message

Note that the AMP #development=1 tool does not check tour structured data, so use the Structured Data Testing Tool as above.

Next up you should verify that the AMP cache will be happy with your page. You can visit:

https://cdn.ampproject.org/c/s/www.tunetheweb.com/blog/implementing-accelerated-mobile-pages/amp/

to see this page in the AMP cache, so you can tweak the URL to your own site. The https://cdn.ampproject.org/c/ is common to all sites and the /s/ part indicates this is from a secure (https) site so exclude that part of the URL if your site is still only on http, and then it's basically the URL of your amp page. The cache will load your page if it does not yet exist, and Google and released information on how the AMP cache is refreshed, but basically it should serve up the cached version and double check it when it does so at most one person will get a stale copy.

Google have now added AMP checking to Google Seach Console (aka Google Webmaster Tools) under Search Appearance -> Acclerated Mobile Pages so after Google has next crawled your site you should see the pages in here and it will highlight any pages with errors.

If you have any issues implementing AMP for your site, you can visit the AMP Project guide to creating AMP pages or the GitHub page for the amphtml project or even raise a amphtml tagged question on StackOverflow. The community are very responsive to questions and suggestions which is a very good thing.

Some learnings from implementing AMP on this site:

I had some problems in implementing AMP for this website:

  1. HTML validation. AMP pages cannot be validated by usual HTML validators due to all the custom HTML they have added. While there are some justifications for some of the AMP specific tags, and the HTML5 spec is being changed to allow custom elements, it still seems like a step back to not implement AMP as a subset of HTML so non-Javascript browsers can read AMP pages too. Also the requirement to have the extra attribute on the key HTML tag in a non-comformant way just seems so unnecessary and purely done for aesthetic reasons and well, because they could. There's an interesting discussion on AMP's non-conformance to the HTML standard here and another here, and the AMP team seem to have decided it's still better to do it this way. It really bugs me that this project felt the need to break the HTML standard in this way when there were potentially other ways to implement this that would also work in browsers which do not support AMP Javascript. Update 14th Feb 2015, AMP now supports noscript tags with standard HTML media tags (e.g. img, video and audio) which at least allows you to support non-javascript browsers with fallbacks. Though it does require basically duplicating content (once as an <amp-img> tag and once as a <noscript><img></noscript> set of tags.
  2. Images require special attention. As well as changing <img> tags to <amp-img> you must provide width and height attributes. These are recommended in HTML to allow the space for the image to be correctly sized and AMP makes them mandatory for the same reason. Additionally my "max-width: 100%" CSS on images was overwritten by AMP, meaning images were wider than the viewport in mobile view. Adding the 'layout="responsive"' code fixed it on mobile but stretched images on large screens. There are a few workarounds to make images work on both mobile and desktop, but they require extra work. Have a look at the differences between the HTML version of this page and it's AMP equivalent to see the differences in some of the pictures. While this won't cause a problem on mobile it does on desktop meaning AMP shouldn't be used for both. Other publishers (e.g. Guardian and BBC) seem to creating AMP content which has a max width avoiding this problem and suggesting they definitely don't see AMP as being something desktop users will use.
  3. No javascript. This is part of the point of AMP since third party javascript can be the cause of so many performance issues. We'll ignore the fact that the way AMP implements this is by adding Javascript for now, but this does mean my pages suddenly lose both the Disqus commenting system and also the Twitter icons. I managed to work around the Twitter issue easily enough (there's no reason to use the slow, heavy, official Twitter buttons any more now that they removed the tweet counts and been meaning to replace the with lighter versions - which AMP has forced me to now do), but the lack of the Disqus comments is just something I'll have to live with. Update October 2016: it is possible to use Disqus on AMP pages but does take a bit of setting up - including a separate domain and using amp-iframe to load it. Works better well in the end, but definitely not as simple as using Disqus on a normal HTML page.
  4. Different Analytics tracking. As of February 2016 AMP has added Analytics tracking. See this article for implementing Google Analytics tracking on AMP. This also allows event tracking (as used on my star rating at the bottom of each page for example) and social interaction tracking so seems pretty fully featured for Google Analytics at least, but does require using the amp-analytics tag and it's own syntax rather than the usual one. Additionally analytics are now performed via the AMP javascript library and so don't have access to the IP address and so can't be filtered out if you use IP address to not view your own internal hits in your analytics software.
  5. No forms. This one caught me by surprise a little and affected me in two ways, which I'll discuss in this point and the next. AMP is intended for articles rather than complex web applications (which would most likely require javascript) so forms might not seem to be needed. However I use a form for my search functionality and that now doesn't work in the AMP version of my page :-( I don't see any really performance hit from using a form on the article pages, so this seems unnecessarily restrictive - though obviously the resulting search page will potentially be slower to load and actually requires Javascript so can't be written in AMP. There plans to introduce some form elements to AMP at some point, but for now, no forms. Update October 2016 - Forms are now supported in AMP.
  6. No menu - despite it being CSS only. I used to use this Pure CSS Off-Screen Menu code a "hamburger" menu drop down in mobile view. Unfortunately it uses a little hack with a checkbox to work and, as per above point, AMP does not allow forms or input tags. So the menu - which was only useful in mobile view does not work in mobile view :-( UPDATE 06-Jun-2016 AMP has implemented a SideBar element, which acts like a slide out menu. I did implemented this on my AMP pages it seems to work well - though limited styling at present (e.g. can't have it drop down as my current menu did). Eventually I dropped the hamburger menu completely for other reasons and the new navigation works better with AMP pages as an added bonus.

So a few annoyances and compromises have to be made to implement AMP. And this is a pretty small, lightweight website with no ads at present and minimal javascript. Bigger sites will likely have to make a lot more compromises - some of which may be too much for some sites to accept. Again you can see the differences of these compromises by comparing the normal version of this page, with the AMP version (updated July 2017: I have removed AMP from this site so the AMP URL will just redirect to the non-AMP version. The article pretty much stays intact and it's just the fluff around it that suffers - which again is entirely the point of AMP. However website owners may complain it allows easy access to their content and is kind of designed for the short term view of looking at one piece of content, rather than encouraging you to visit the rest of the site, since some navigation items (e.g. menus and search) and some engagement items (e.g. commenting systems) are either completely absent or very basic versions. Then again the same argument could be made for RSS and other syndication technologies.

It also means running two versions of each page - a HTML version and an AMP version. The AMP team do suggest you can have one AMP-only page if you would prefer not to have two pages, but this seems impossible at the moment when key items are missing and non-AMP or non-Javascript browsers would fail to show the pages.

Performance Improvements with AMP:

So we've talked about how to implement AMP, and the compromises you might have to make to create AMP pages, but what's the net benefit? How much does it improve your website? Well since I've implemented both versions for all these pages, this is very easy to measure. Looking at a typical page (my blog post questioning the need for AMP) you see below:

AMP versus a normal page

The results are impressive, even for a simple site like this without much bloat (in my opinion!). The Start Render time drops from 1.275 seconds to under a second (0.976 seconds) and the overall load plummets (from 483kb to 121kb) as does the number of resources loaded (29 versus 6). Very nice!

However there a few caveats. For a start this does not include images on the page. They are loaded as you scroll down. This may make sense (why bother wasting bandwidth displaying images until you scroll down and need them?), but there is a noticeable delay after the picture comes into view before it's downloaded (in Chrome on desktop at least - on the iPhone I didn't notice this delay but not sure if it's loading in advance there). This is actually quite annoying and gives the impression of a slow site - the exact opposite of the intention of the project! Including the images takes the total page weight up to 193kb - still a good bit smaller though.

Secondly is that the main improvements are due to inlining CSS and removing the Disqus commenting system. In fact if we take those two steps manually we see the following:

AMP versus a optimised page

As you can see if we inline CSS and remove the Disqus system, the Start Render view drops further to 0.689 seconds - even faster than the AMP version by a significant amount. This is not surprising since AMP loads some extra Javascript and then uses that to process the AMP specific parts of the page - so of course it's going to have some extra overhead to doing this natively but the difference is quite considerable.

What's perhaps more surprising though is the third test, where we inline the CSS (as an AMP page would have), but leave in the Disqus commenting tool. Here you can see as slight increase in Star Render time (though still faster than AMP version), and back up to full page weight as expected. What this shows is that the Disqus system, while it adds a few hundred kilobytes to the page, and causes a lot more network requests, doesn't actually slow down the initial page load. The Disqus team have actually optimised their code quite well - which is not really surprising seeing how popular it is as they wouldn't really want to be responsible for slowing down lots of pages and would get complaints if they did.

The repeat views are a similar story. For the AMP pages they load a good bit faster than standard pages, but not as fast as optimised versions, though the Disqus optimised version is slightly slower here (document starts rendering at 0.309 seconds versus 0.109 seconds on AMP).

An important point is that none of the optimised views have any of the restrictions or downsides mentioned above, nor with the added hassle of managing two similar pages. So it is quite easy to have the performance of AMP, without the restrictions it needs. In fact, because AMP forces you into making these performance improvements anyway (to inline your CSS and also convert your page to AMP HTML), it's easier to make these improvements outside of AMP than to have to also cope with the restrictions it forces on top of you.

Learnings from implementing AMP

When I initially heard about the project, I thought AMP was unnecessary. If people really cared enough about performance, I thought, then they could get it without being forced into a restrictive framework. I'm still of that view after this experiment with AMP and in fact that it is not even a subset of HTML but it's own little custom format really, really, really annoys me. The point of the web is to be open to standards and not to just ignore them because you think the project you're working on is more important than that.

While the ideals of AMP are lofty, and the results are undoubtedly impressive, the implementation effort once you start seeing how restrictive an non-standard it is, raises some serious questions. There's a lot of very clever people working on AMP and they have massive backing of companies, but I just feel their efforts could be better placed in fixing the web rather than in replacing it with a "web-lite". The team are very responsive to improving AMP on the AMP GitHub page but seem wedded to the basic underlying principals that I disagree with (AMP is different to HTML, AMP requires Javascript, AMP requires custom tags instead of standard HTML tags).

Implementing AMP on this site has been a bit of a mixed bag. On the one hand, I found it frustratingly restrictive - often for no good reason. On the other hand, it's been an interesting experiment, and it wasn't actually that difficult due to the fact this is a new site, completely under my control and without using a third party CMS. It has also forced me to examine some bits of this site that I've been meaning to look at for a while. The Twitter plug-ins were far too weighty for no good reason, and I've been meaning to replace them with lightweight versions for a bit and have now done that. Also it was worth a proper look at the performance benefits of inlining CSS, which while impressive, I'm still holding out against (see my blog post on why inlining CSS is not for me for more details on that). So, despite my negative opinion of the project itself, I can see the positives in AMP bringing the performance issue to the forefront and making sites question the need for their baggage. I would be quite happy if AMP opened up that much needed performance conversation for site owners and no one implemented it, but instead lots of people with previously no cares on performance seem intent on jumping on the band wagon instead of fixing their sites.

Even the name (AMP) is not very distinctive so when looking for articles and help on this you have to revert to Accelerated Mobile Pages, which is a but of a mouthful. Even searches for HTML AMP lead pages about &amp; (the HTML code for the ampersands - &). This may seem like a small, moany thing to say but would have much preferred if they'd chosen a more distinctive name. Amphtml is a little better but not all sites use that. Anyway probably just being overly critical now...

I think the big elephant in the room is how Google will treat AMP, and whether non-AMP sites will effectively be penalised in search rankings by not implementing AMP. It would appear for example that the top stories carousel will only display AMP pages, so it seems publishers will be effectively forced into AMP. To be honest that was one of the main motivations for implementing AMP onto this site - to see what SEO impact there will be, so will keep you posted on what difference that makes.

Update - June 2017

Nearly two years on after implementing AMP I've written another post on further thoughts on accelerated mobile pages. If this article interested you then check that out for my latest opinions on that.

Want to read more?

Further reading on the issues with AMP

This page was originally created on and last edited on .

How useful was this page?
Loading interactions…