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.
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 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 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 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 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
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 (so is below the The Line of Death) and it is not shown anyway after you scroll down.
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 but it's usally pretty easy to work out.
Now I know why AMP have used the Google domain and why amp caches exist, but even if you know that it doesn't affect the end result - AMP has broken some of the basic tenants of the Web through the current implementation.
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 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. I don't know if that's a Safari bug or not and, quite frankly I 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 think as displaying images on a major playform - this is a fundamental part of browsing the web and has been almost since it was launched! 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! This is even more difficult on other platforms like Twitter where there is no one click solution to switch to the real HTML page. 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.
We also have the fact AMP is forced on you. As a site owner 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 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 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?
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),
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.
Update - July 2017
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.
Want to read more?
Further reading on the issues with AMP
- AMP Project Home Page.
- AMP Keynote at Google I/O 2017.
- Kill Google AMP before it KILLS the Web.
- AMP Conf Live Stream I particularly recommend the panel discussion at the 4:53:15 mark.
This page was originally created on and last edited on .Tweet