Google Acknowledge Web Broken – What Next?

On Wednesday 7^th  October 2015 Google announced Accelerated Mobile Pages (AMP) and acknowledged the web is broken from a revenue perspective. Google’s introductory blog states “Publishers around the world use the mobile web to reach these readers, but the experience can often leave a lot to be desired. Every time a webpage takes too long to load, they lose a reader – and the opportunity to earn revenue”. Authoritative voices like those of Adobe, The Guardian, BBC, The Wall Street Journal, are all supportive.

What all these companies are telling us is that despite deploying the supposed best technology, people, design techniques and practices the web isn’t fulfilling its revenue potential due to slow performance. Whilst AMP as a solution is designed for publishers suffering from this problem, what about other sectors like retail or travel? Presumably they suffer the same consequences from poor performance but Google does not yet have a solution to offer.

How did this happen?

For many businesses performance has not been a mandatory feature or consideration when briefing agencies and technology teams. Performance has been assumed by virtue of utilising the best technology, not stated as a functional requirement.

Performance has rarely been measured in the real world. However there is a big difference in network performance when used in an office environment or on a packed commuter train.

Readers of publisher’s content have turned to Ad Blockers in an attempt to improve performance removing all revenue potential. Apple’s release of iOS 9 made Ad Blocking an easy technology to deploy and understandably publishers and advertisers are worried.

Google’s AMP announcement requires those responsible for website revenue to explicitly state performance requirements and ensure that web professionals adhere to these requirements.

Different device = difference content

At its core AMP involves creating multiple web pages with the same content. One of these web pages targets high bandwidth larger screen devices, the other specifically mobile with stripped down simple pages. There is no reason why more than two pages can’t be used, perhaps targeting tablets or other categories of device.

The doctrine of Responsive Web Design (RWD) over the last 5 years has been to stay away from such techniques. Google, and the authoritative companies behind AMP, are implying if you care about revenue you need to segment your web pages by device type.

AMP is a clunky and technically complex way of achieving this goal involving web professionals learning new skills, increasing complexity and cost. Modern platforms ranging from WordPress to Sitecore, EpiServer and SDL all have the ability to adapt content to different devices through device detection extensions.

Figure 1 – Professional Device Detection enables content to be segmented easilly

Professional device detection, designed in this decade for the modern web, enables the web platform to identify the type of device and serve optimised content. Such content can be optimised for performance in addition to layout and navigation. The best device detection achieves over 99.9% detection accuracy, is extremely fast and avoids complex JavaScript.

Technology to avoid

Google’s technical explanation behind AMP places much of the blame for disappointing performance on poorly implemented JavaScript. JavaScript is the layer of technology that runs in the web browser turning simple web pages into complex computer programs. It now seems Google’s message is to avoid JavaScript to deliver fast performance. Presumably it is reasonable to assume the voices backing AMP have already gone to every effort to make sure their JavaScript works as effectively as possible. If they can’t make it work then it is probably best minimised or even avoided all together.

What next?

It has only been a week since Google acknowledged that from a revenue perspective the web is broken. Many companies and existing projects are yet to fully assess the impact. Embracing AMP, and the equivalent solutions from Facebook and Apple will be time consuming and costly. They don’t offer a solution beyond publisher’s static pages.

However simplifying web content using existing technology provides a universally accessible solution to improve performance everywhere. Here’s a summary of the key next steps:

• Treat performance as a feature for all web projects ensuring it is measured in the real world
• Segment web content by Smartphone and Desktop – consider Tablet as a third segment
• Minimise, or on mobile avoid, JavaScript

Doing nothing is not an option. Challenge technology delivery teams to deliver performance in the real world and optimise revenue.