site logoTune The Web

OPINION - Further thoughts on Accelerated Mobile Pages (AMP)

Introduction

This is my third blog post on AMP (Accelerated Mobile Pages). My first post (Do we really need Google AMP?) was published back in October 2015 when AMP was first announced, and my second (Implementing Accelerated Mobile Pages) was published in December 2015 and from then on I've published all posts on this site in both standard and AMP format. So it's been over two years since launch and I thought it was worth a re-review, following my initial scepticism.

AMP success story

In a lot of ways AMP has been phenomenally successful. With Google's push, it now powers 2 billion... pages covering some 900,000 domains [and] these pages are loading twice as fast as before. The publishing industry have certainly embraced this fledgling technology. Despite being pushed heavily by Google it is open source, and in the short time it's been around over 6,000 commits from over 350 authors have on it's main GitHub project. Some of the biggest sites in the world have added support for AMP, initially for media outlets but increasingly beyond that. Ebay now offers all it's pages in AMP.

However better than that is the user experience. AMP Pages load fast! The aim of AMP was instant loading- not just fast loading but instant loading. When you click on an AMP page in Google Search results it is amazing to see how fast this loads. This is due to many reasons, some of which are standard web performance techniques and some of which are due to the way Google treats AMP pages in preloading them. This has negative connotations, which I'll discuss in more detail below, but the results are impressive. Mobile usage is over taking desktop usage, but performance is a problem on mobile and AMP seems to be providing a solution for that. Once you leave the comfort of wi-fi and start to suffer from congested or low speed mobile networks then Internet use quickly grinds into uselessness. You don't get this with AMP pages because, in general, AMP pages are not allowed to be slow.

Problems with AMP

My original blog post and it's follow up, discussed some of the problems with AMP: it breaks the standard the web is based upon, it uses Javascript to address problems with Javascript, AMP pages can actually be slower than non-AMP pages because of this need of Javascript, it's force on you by Google favouring AMP pages over equally fast pages if you want the SERP advantages Google gives AMP pages (lightning bolts and Top Stories carousels), Analytics tracking becomes harder with AMP, it creates different pages for Mobile, it requires as much effort to implement as it would take to improve the performance of your website without using AMP... etc. And these are all still, on the whole, problems. At the first AMP conference in 2017 they hosted a panel (available here at the 4:53:15 mark), which discussed just these problems (and kudos to AMP for not shying away from these discussions).

In addition, one point I didn't highlight enough that has caused a lot of concerns, is the fact that AMP pages are served with a Google URL. Now there are good reasons why AMP forces use of a Google cache rather than just load the AMP page directly from the publisher's own site, and there are also further optimisations that they make for you in that - without any effort required on your side. However the URL is a key part of web browsing and showing a Google URL rather than the original site's URL leads to concerns about credibility. Pages from crazyfaroutwebsite.com (not a real website at time of writing) and bbc.com are given equal credibility based on the URL. AMP tried to address this somewhat by adding a header bar (see screenshot below), however this doesn't fix the address bar (so is below the The Line of Death) and it is not shown anyway after you scroll down.

AMP header bar showing different URLs

Aside from the credibility issues, there have been concerns that Google is "stealing traffic" from original site owners. It's true that AMP compliant Ads and AMP compliant analytics will still go to the original site owner, and that site owners also benefit from this being served over Google's infrastructure (they are effectively getting a free CDN to serve this traffic), but it's still difficult to argue against the fact that Google benefits here. The top stories carousels for example allow you to swipe left and right to see the other stories from that carousel, across other domains (even competitor domains). I blogged previously that AMP "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", and this is yet another symptom of that.

Separate to that has been concerns about seeing, and sharing the original URL, though an updated version of the AMP header has addressed this a bit:

AMP header bar with option to click through to original URL

However, ignoring all of the above, as these are more opinion preferences, one of the biggest problems I'm increasingly seeing with AMP is that they do not work - AMP pages are often broken pages compared to HTML. I suspect this is caused by poor automatic conversion of AMP pages - creating AMP pages takes some effort and so many platforms have attempted to automatically convert your pages to AMP (e.g. Wordpress has plugin, Ghost automatically converts your pages) but these don't always work. Having converted this site to AMP I know I experienced a number of problems, for example with mobile menus, and other UI items that needed to be fix to make the work with AMP, so having some magic tool to convert pages, which was not written with any knowledge of your specific website was always going to be a difficult task. Too often I see missing elements and other problems that make the pages look broken. Often there are blank spaces that would be filled by ads on the real page but have been stripped out in the AMP conversion and the text has not been shifted up to fill the space. Other issues include missing commenting systems. All in all it feels like a substandard experience and more often than not, when I load an AMP page the first thing I do is click on the header to load the real page: AMP has actually started slowing me down instead of speeding me up as I need an extra click to get out of it! When you do load the real page, yes it is slower to load, and you get all the advertising crap, but you also see branding and styling differences - fonts, backgrounds and colours are often different. AMP is great at giving the raw content quickly, but often at the expense of in the content that the publisher originally intended to show you. I took great effort to make the pages on this site as identical as possible in AMP and normal HTML formats (I even managed to get Disqus working with a little hackery) but others do not seem to be taking this same care. Even if they do all work initially, they can break in future as AMP evolves so require care and feeding. While writing this article I discovered some issues when viewing amp pages in desktop mode that I'm sure didn't use to be issues (the search function at the top of the page doesn't display properly, and my Disqus comments sometimes don't load properly in desktop mode without flicking to mobile view first to force a frame resize). This is yet another problem of running two pages of "identical" content, which AMP forces you into - some argue you can just have AMP pages and skip the normal HTML pages but the problems I see with desktop here are another reasons why I wouldn't recommend that.

Is AMP worth it?

So is AMP worth it? There are some definite downsides, but if the site benefits from faster pages and the extra UI that Google provides in the search results then it might be worth it. Well here it gets a little tricky and we enter the lies, damned lies and statistics zone. The AMP team cite many good statistics since sites have adopted AMP, but there are reports of AMP pages generating half as much revenue as regular pages. I can't honestly comment on those sites, but I have been using it on my site since launch so can talk about that. However I should caveat this by saying that this is a very niche site. Much as I would like to say I do, I don't get as many visitors as a large media site does. I also don't feature in any of the top stories carousels as far as I'm aware as these are typically not shown for search results were my site features. Also a lot of my posts here are very technical posts, that people may prefer to look at on their desktop, so will not be as relevant in AMP. Finally I also have a very optimised site without a lot of the advertising and other Javascript cruft that other sites have so my pages are almost as fast even without AMP. However if you are a small firm, or are a small, individual blogger like me, considering implementing AMP and are wondering if it's worth it then these stats may be of interest. I looked at some of the popular pages on this website from January 2017 until now (10th June 2017). I deliberated excluded 2016 as AMP pages were not shown in search results until near the end of 2016 and similarly other items on the page (like Disqus comments) were possible until then. The results I see are shown below:

Engagement on AMP pages versus normal HTML pages

The first two pages are for some of the technical tutorials and they show very few AMP views - these pages are obviously mostly viewed on desktop so no benefit from AMP for them.

The next page on the What does the Green Padlock Really Mean? is more interesting. Half of the views are from mobile. The average time on the page is up significantly, but the bounce rate is slightly higher too. Now the way Google Analytics measures the time on the page is based on clicking on another page. When you don't visit another page (as 93%-96% of the visitors here failed to do), then it can't measure a time on the page. So I'm a little sceptical of that metric to be honest.

The final example is from my original AMP article. It shows the a good amount of traffic from AMP (23%) though ot as high as above, but a reversal of average time on page - perhaps justifying my scepticism above. Bounce rates however are similar.

I looked through other statistics with similarly inconclusive evidence. When filtering by device category I actually saw higher engagement from my mobile users from non-AMP versions of the pages. When looking at click through rates for search terms on Google, mobile (where the AMP affect should help most) were lower than desktop. Looking at other sites I manage (that haven't implemented AMP) this appears to be normal but certainly it doesn't look like my implementing AMP on this site has suddenly lead to a lot more click through thanks to the lightning symbol in AMP.

All in all I'm underwhelmed. As I mentioned I'm already a fast site, and really am quite small in the grand scheme of things, but I would have though the UI gains from implementing AMP would have led to a noticeable difference but I'm honestly struggling to see one.

Summary

When I implemented AMP initially I was skeptical and now over a year later, I'm no less skeptical. In fact I'm actually more anti-AMP than I was before. While I admire the aim of it, I still don't like the technological principals it is based on, nor Google's forcing it on people with the UI focus it is giving. I would love fast sites (like mine!) to get the lightning bolt UI in search results and therefore be rewarded for investing in performance - regardless of whether this is based on a particular platform like AMP, or through other techniques. Now I've argued this before and AMP claim that Google cannot know your site is fast without AMP, but I dispute this! Google do know this from crawling your site. OK a site owner might have changed it, or might load stuff differently for users than for Googlebot, but these are not concerns for other SEO measures so why so for performance? This was discussed in the AMP Conf panel discussion (from the 5:12:30 mark),

As a framework, AMP is very impressive. It packages up a lot of tips and tricks to ensure the site is performant, and the AMP Cache further adds to this. Recently they stated the AMP cache will automatically implement Brotli compression for example, which may not yet be available to web publishers on their own software so thing like those are positive. However I've always said that sites can use a lot of those techniques themselves and improve the performance of their HTML pages without the negative downsides of AMP. They cannot get not all of the performance improvements - some of them are specific to how Google interacts with AMP - but that's part of my issue with the AMP project. So it is a very clever platform and has clearly been created by some very clever people. The number of components is growing and, while it's not quite at the level of something like Bootstrap for example, it is a nice collection of components and the performance gains for those that have not optimised for performance is very nice when it works. However it is (or at least initially was) aimed at articles, rather than complex web apps so those components are needed less - they've been primarily created to compensate for the restrictions AMP has inflicted on itself (mostly "no Javascript").

The lack of Javascript is indeed one of the best things about AMP because publishers are forced against the things they are doing which is making their websites slow. Web developers do typically care about performance, but they get overridden by business users or marketing who fill the page with all sorts of Javascript tracking. Google could force that in other ways - make performance a much bigger ranking signal for example. Or alternatively have a script, which you can add to your page which automatically delays all known bad/unimportant Javascript scripts so it still works (and is loaded from your URL) but stops slowing the initial page load? Would that lead to vast improvements without the downsides of AMP? If web pages were faster, and without all the Javascript crap, then would they need to be "instant" or would that be sufficient? Would all the extra tricks that AMP and the AMP cache does be as necessary or could the AMP Cache then become a voluntary CDN that people can use if they want to?

The fact that a lot of publishers have jumped on AMP is positive. I think they've done it for the wrong reasons (for SEO reasons rather than because they really believe performance is important), but regardless AMP pages are considerably faster. And if that led to web publishers caring more about performance then that would be a great thing! If, like Mobilegeddon, this forced publishers to sit up and pay attention to performance, and then it quietly went away, or at least became less forced on sites, then I'd be very happy.

I still question the gains from AMP - particularly on this site. So I am considering pulling AMP from this site. I'm not a fan, as you will have gathered, and don't see the investment giving me anything. Now I'm a very small website in the grand scheme of things and, for that and many other reasons, am probably not the ideal candidate for AMP, but I gave it a go for a good while and am not seeing the benefits.

To end on a more positive note, one thing I would definitely commend is Google's openness for the project. I had concerns that it was so tied to Google so, despite being touted as an open source project, it would not be treated as such, but those fears have been largely unfounded. I mentioned above the open and honest panel of the issues at AMP Conf 2017. In addition to the the level of engagement on the GitHub AMP home is very high and the AMP community actively encourage contributions, whether that be with code commits, or just questions and suggestions.

This page was originally created on and last edited on .

How useful was this page?