I guess you know AMP. Accelerated Mobile Pages. It is said to become one big next thing in 2017. Why is this so and why do so many people have problems with it—at least those who should be the most happy about it?
AMP is backed by Google and often referred to as Google AMP. But it is an open source project with many contributors of many corporations. The reason it is strongly connected with Google is it’s distribution strategy.
Give them a reason to make their sites fast
Google saw a problem they tried to solve with AMP: Bloated mobile websites and an unsatisfying mobile user experience. To say it straight: speed. Delivering a responsive web design that looks great on the big screen and that loads fast—meaning less than four seconds on 3G—is not an easy thing to do. The visual power of a website is still judged at desktop size and people want large images and a lot of design. Mobile is something you have but not something you love. These are the typical problems of corporate sites, but websites of content creators like newspapers and blogs face even harder challenges. They make money with advertising and are forced to load the scripts of their ad vendors into their sited as well. And these have a reputation of being literal performance killers.
Who want’s to pay a good amount of time and money on something you don’t even see?
The way Google, as a leading force behind AMP, tries to make mobile sites faster, is to incentive decision makers and marketing people. Google knows that developers always feel the need to increase performance, to cleanup the code, to optimise load times, server requests and all these things a fast website needs. And they know that developers often stand alone. Who want’s to pay a good amount of time and money on something you don’t even see? So, what Google did, was offer a reward for speed optimised websites. It is known that load time factors into Google’s page rank. Don’t get confused here: being or not being an AMP-site, does not influence your page rank, load time does. That was a nice move, but didn’t really change the priority for fast mobile sites. So Google increased the awards by marking validated AMP-sites with a lightning bolt on Google’s search results. In addition they started to deliver AMP sites on their own CDN (which means Googles own, very fast servers) in some kind of popup window on mobile devices, giving AMP content a special appearance that is meant to appeal to mobile users.
And guess what: it really works out
The idea to make fast mobile websites interesting for decision makers, gives AMP a push and an awareness it would never get, if it was a simple Java Script framework. Many content creators deliver their website as a regular site and as an AMP format. But now developers form a massive front against AMP. It’s really become a controversial topic. Coders complain about AMP being proprietary, being dependant on Java Script (and thus not progressively enhancing), being a second code base to maintain, being much too restrictive. And they certainly are right.
But would they have these issues if AMP was a simple, optional framework they could choose to use or not to use? The force Google uses to push a good idea—making the web faster—into the market, means a requirement that’s pressed on developers. Suddenly their superiors force them to make their mobile sites fast. And to use AMP for that. Even though they might have a better, more appropriate way to achieve this, they are advised to use AMP. What a frustrating experience.
And then again, it fails
I guess, if AMP was an optional framework many developers would use it voluntarily, as a fast and easy way to speed up a mobile site. And I very much appreciate Googles efforts to find a solution for this problem of bloated mobile websites. And I think it was not only brilliant, but courageous and necessary to address the decision makers in a company rather than the developers.
But what this approach failed to solve, is the different goals developers and marketers have. Sure, a clever coder might have a means to address this web performance issue to the board, now that AMP is here, but the only solution he or she can offer is using AMP. Because AMP not only makes the site faster but promises search engine benefits as well. AMP combines the needs of marketing with the intentions of developers—but only so much.
AMP points in a right direction but doesn’t really solve a problem. The real problem is that a user-first-mindset is not established in most corporations. A user first approach would demand ideas for highly performant mobile pages and brilliant ideas to market the corporations products. But this is a problem beyond AMP.