Accelerated Mobile Pages – is Google’s mobile project the best approach to faster browsing?

Date: 15th May 2017
Author: Louise Arnold

Taking fast and responsive performance to the next level

At SciVisum, we often talk about the need for websites to be as fast and responsive as possible, especially as customers are increasingly engaging online via mobile devices. There are plenty of practical ways to optimise performance so that mobile browsers can enjoy a good experience – we’ve blogged about these before – but the stakes have been raised by the advent of Google’s Accelerated Mobile Pages (AMP) project.

Pitched initially to the publishing sector, and heralded as the cure-all for bloated and slow-to-respond websites, AMP could represent a huge leap forward for easier online interaction but is it actually tackling these challenges in the right way?

Accelerated Mobile Pages

Are Accelerated Mobile Pages taking the issue of control too far?

The main source of confusion – and anxiety – is that AMP comprises a collection of components, rules and tech that together create a proprietary solution that appears to restrict rather than free the medium.

With AMP, a single, Google-hosted JavaScript file turns a bunch of prescribed web components into working elements – no deviation from this is allowed, so creativity is significantly limited. Only limited styling is allowed and no third-party scripts. This means that the opportunity for publishers to design their own user experience is diminished, which, in turn, makes it more difficult to provide a point of differentiation in a competitive online world.

Google’s restrictions do help to make Accelerated Mobile Pages fast but you could argue that by following similar self-imposed rules, publishers could achieve quicker results, without the need for AMP.

The problem of Google-cached pages

One of the most contentious issues for publishers is that AMP returns a cached result, rather than the original page. The use of an AMP page delivers pretty much instant results; the problem for the originator of the information is that while the user may believe they’re accessing another website, they’re actually still on Google. Let’s say you’ve Googled a Telegraph article and clicked on it; with AMP, you’ll be viewing Google’s pre-rendered version, not the Telegraph-hosted one – as evident from the URL.

Developer Andrew Betts sums up the problem in his excellent AMP launch review: ‘Accelerated Mobile Pages forces technical restrictions on publishers that limit their ability to create value for their customers, limit their ability to further engage the user beyond reading the initial article, and prevent them iterating on their business model with the freedom they would normally have.’

Now, Google could pre-render the page at its original URL but they don’t – and won’t – because then they’d have to trust others to stick to the rules, which, from Google’s perspective, is a non-starter, given that websites will often try to game the system to gain a commercial advantage. But, surely there’s an argument for allowing publishers to host their own AMP pages with the threat of sanctions if they don’t play by the rules?

Enjoying this post?

Join us today for more great news, tips and research directly into your mailbox.

As author Jeremy Keith says in an article on the subject: ‘Google says it can’t trust our self-hosted Accelerated Mobile Pages enough to pre-render them. But they ask for a lot of trust from us … I’d like to see trust work both ways.’

The way forward

We’d all like websites to be as responsive as possible. What’s worrying us about AMP in its current form is that not only will publishers have to follow restrictive practices to stay within Google’s parameters, but they’ll also have fewer opportunities to engage with customers and capitalise on that initial contact.

Maybe AMP doesn’t have to be an all-or-nothing solution. If Google were to provide a selection of components and allow publishers to pick the elements that were the best fit for their site, it would be a step in the right direction. For instance, developers may want to use the clever ‘amp-img’ component which improves load times but currently can’t unless they adopt the whole AMP runtime which prohibits the creation of any additional JavaScript.

Hopefully, Google will listen to the feedback and adapt AMP as it progresses. In the meantime, publishers need to continue to look carefully at how their websites could be optimised for cross-platform use, prioritising speed and the delivery of a quality user experience. As developer and author Tim Kadlec points out: ‘Optimistically, AMP may be a stepping stone to a better performant web. But I still can’t shake the feeling that, in its current form, it’s more of a detour.’

Learn more about how monitor your website for mobile performance. And for more info on how to optimise your website for mobile traffic, check out SciVisum’s blogs, or call to request a demo.

Further Reading

Top 5 mobile performance issues uncovered by real iOS and Android browser monitoring

Get closer to your end user’s mobile experience with Network Emulation

 

Top