Date: 15th May 2017
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?
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.
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?
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.
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.’