OPINION - Further thoughts on Accelerated Mobile Pages (AMP)

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.

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 not a Google-only platform and is in fact open source. 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 performance. 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 more favourably than those built with other frameworks by preloading them. This has negative connotations, which I'll discuss in more detail below, but the results are impressive. Mobile usage is overtaking desktop usage, but performance is a problem -particularly 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.

My original blog post and it's follow up, discussed some of the problems with AMP: it breaks the standards 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 forced 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. Two years later, these are all still, on the whole, problems with AMP. 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 when viewed from Google Search Result Pages (SERPs). Now there are good reasons why Google 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 and is below the The Line of Death. Additionally it is not shown anyway after you scroll down, nor on other applications that use AMP - only if an AMP page is launched from the Google cache.

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, but somewhat related, are the concerns about seeing, and sharing the original URL, though an updated version of the AMP header has addressed this a bit:

This also provides a nice way to escape out of AMP and see the real page - however this toolbar only appears when you are in the Google AMP Cache and not when you've stumbled upon an AMP page by some other means. Twitter for example now sends you to the AMP page instead of the real page, and to revert to the real page you need to open the page in your browser and then edit the URL manually - assuming you know the URL of the real page, though that is usually pretty easy to work out.

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 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 fixed to make them 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. AMP lazy loads images to improve performance but it often doesn't work on my iPhone. Whether that's a Safari bug or not I, quite frankly, don't care. I don't see the issue when I load the non-AMP pages. Now I did eventually moan about this on Twitter and the AMP team were very responsive and they identified and very quickly fixed a bug with lazy loading images on iOS devices and, while I'm very impressed with that response, it still goes to show that AMP is overly complicated when they can break as simple a thing as displaying images on a major platform. Images are a fundamental part of browsing the web and has been almost since it was launched! Other issues include missing commenting systems and other parts of the web page. Blogs on the Ghost platform for example fail to include Twitter Tweets proprerly on AMP and instead revert to a simple quote. 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! As mentioned above, is even more difficult on other platforms like Twitter where there is no one click solution to switch to the real HTML page. If you do switch to the real page, then yes it is slower to load, and you get all the advertising crap, but you also see branding and styling differences from the AMP page - fonts, backgrounds and colours are often different and often worse.

We also have the fact AMP is forced on you. Once a site makes AMP pages available, certain sites will automatically use the AMP URL in preference to the standard URL. Google for example does this in the search results while browsing on mobile, and uses the Google AMP Cache instead of your domain. Twitter has also recently changed to using AMP pages if they exist while on mobile. So you paste the normal URL in a tweet, and then if you or someone else clicks on that link on mobile then it will automatically send you to the AMP version which, as discussed above, is often broken. Of course sites owners have the choice whether to use AMP or not, but end users do not. There is a no "send me to real URLs please not AMP ones" setting in Google search or Twitter so you have to load the AMP page (admittedly fast), but then figure out how to load the real page if you want to. Which is both annoying and time consuming.

AMP is great at giving the raw text quickly, but often at the expense of the actual 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 the Disqus commenting system working with a little hackery) but others do not seem to be taking this same care. And then, 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 didn'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, are just some of the reasons why I wouldn't recommend that.

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. Christian Oliveira has written an excellent post on how you should understand the stats you are reading rather than just the headline. The AMP team cite many good statistics since sites have adopted AMP, but on the other side there are reports of AMP pages generating half as much revenue as regular pages. I can't honestly comment on other 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 where 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 deliberately 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:

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 not 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 throughs thanks to the lightning symbol in Google search results.

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 thought the UI gains from implementing AMP would have led to a noticeable difference but I'm honestly struggling to see one.

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 these are benefits of using the AMP cache like a CDN rather than of the AMP format. In fact many other CDNs offer similar optimisations. I've always said that sites can use a lot of those techniques themselves and improve the performance of their regular HTML pages without the negative downsides of AMP. Sites cannot get 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 as Google are playing favourites and telling me which technology to build my website in! 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 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.

After a clicking on yet another article that didn't load properly in AMP I finally decided enough was enough and AMP is not something I like or want to support. Personally I've not had as many problems with my site as I have with other sites - perhaps becasue I hand crafted the AMP conversion process rather than used some automatic tool that wasn't written for my site? At the same time I have not seen any gains as mentioned above, and don't want to inflict on my readers, what I don't like on other websites. So I have turned it off on my site and redirect all AMP pages back to their non-AMP equivalents. Will see if this has any impact on traffic or other SEO factors and report back but either way I don't want it on my site.

This page was originally created on 11-Jun-2017 and last edited on 28-Jun-2022.