Published on April 12, 2016
There was a lot of fanfare a little while ago about AMP (Accelerated Mobile Pages) and Google favouring these pages over non-mobile optimised pages. Much like every other Google announcement there was a flurry of advice and people recommending you take up the new guidance but there was also a flurry of dissention from developers as they regarded this as a Google-specific way of coding for the web.
At the root of all of this change is the increasing popularity of the mobile web. As more and more of us access the web on our smartphones and tablets, eschewing the traditional desktops/laptops, researchers are seeing our behaviour change. Like a generation of kids with ADHD, we aren’t willing to wait for a page to load, with the bounce rate being as high as 58% for web pages that take nearly ten seconds to load (https://www.soasta.com/blog/mobile-web-performance-monitoring-conversion-rate/). This may make AMP seem like a no-brainer but what it doesn’t do is address the underlying issue – code bloat, poorly coded sites and other technical issues which are not faults with HTML or the web but with the way these sites are built.
While digging in to AMP for implementation on my blog, I found a large number of conflicting opinions which prompted this post. While some people seemed heartily in favour (https://moz.com/blog/accelerated-mobile-pages-whiteboard-friday) others were neutral (https://auth0.com/blog/2015/10/12/whats-the-fuss-with-googles-accelerated-mobile-pages-amp/) but some were falling into the negative camp (https://www.tunetheweb.com/blog/implementing-accelerated-mobile-pages/). I’m not sure how much of the positivity was based in the desire to win business, and how much of the negativity was based on the (sometimes seemingly unnecessary) severe restrictions but it created a sense of ‘us vs. them’.
As I looked to implement AMP on my blog, I decided to look at a large publisher and see how much of a difference in page load speed and score it would produce. Taking the Guardian website as an example, I chose an article at random and checked the page load speed on GTMetrix. The article I chose at random showed a less than one second (0.7sec) page load speed improvement. The original was a tight, fast-loading page:
The AMP page didn’t really improve on the page load speed much:
Given the cost of implementation, there is a questionable value add on less than a second. Both of these pages also fell within the magic 2.4 second sweet spot for conversions (had this been a commercial website) as reported by Soasta in their analysis of the mobile web (https://www.soasta.com/blog/mobile-web-performance-monitoring-conversion-rate/). Other pages which were more image heavy (within Fashion) did show more significant improvement on page load speed but again these image-heavy pages were still loading in the sub-6sec time frame.
This minimal improvement and current lack of algorithmic benefit (there is currently no known additional benefit from implementing AMP over pure fast mobile pages) makes it a difficult element to justify independently from a full site (re)build from an SEO point of view. It seems currently to be better to build a well-optimised site which loads quickly on tablet. mobile and laptop so as to benefit from this element of the ranking algorithm. So while not dismissing it completely, for the moment I would recommend a technically optimised site for better SEO, rather than a whole additional AMP site.