Better, Faster, Stronger
When Accelerated Mobile Pages (AMP) first came to light in 2016, there was a lot of discussion around what it would mean for the web, and what its “intentions” were. And apparently, that is still the case. But is it a necessity? Do I need AMP on my own website you ask?
What it is. AMP is an open-source HTML framework. It is a set of rules to build a certain ‘version’ of a website. That version of a particular website focuses on stripping down webpage styling options, limiting functionality, and caching search content in advance, among other things.
The stated intent is speed. AMP sought to speed up load times for pages – largely with the goal of delivering that experience at much faster rates to mobile users than was previously the case. And it did. Cutting time to load such content by a large factor.
There are many articles, as well as Google sponsored documentation, giving technical details on how AMP works, why it is useful, and the statistics to back all that up.
And much of it is a headache. Because what we really care about is AMP – not in the technical sense, but the business sense.
What does AMP mean to MY business (product, content, or branding). Read on for that and the problems many have with this standard.
AMP Breaks Convention
AMP was not designed within the framework of the standards bodies for webpage design (W3C, WHATWG).(1)
You can have perfectly valid webpage design and it will send up a ton of apparent ‘errors’ because AMP doesn’t like what you’ve done – even though it is valid by the well worn guidelines of web design.
FerdyChristant.com hilariously makes this point with the AMP project website itself – which generates multiple HTML errors. (See his article in footnotes. Worth a read).
Does a user care? Probably not. It should load properly on their phone. Do web development teams care? Most definitely.
AMP creates stringent rules for how they can design and by extension both the functionality options and ‘feel’ of a particular website or branding identity. Their clients most definitely care when limitations arise over the ability to implement a particular strategy for their product.
When There’s A Fork in the Road…
Luke Stevens builds on this point to re-frame it as a breakout of the web itself into effectively two different realities.
One is the network we are used to. It consists of a lot of variety in web design by following acceptable though not AMP-centric practices.
The other reality is a new AMP-only landscape, whereby content must adhere to some stringent rules. And he points out the consequences of that approach, calling it the “Google Web Fork”. (2)
The way Stevens thinks of this is that it is less about how best to speed up the web and more about how to cynically co-opt it. He uses the phrase “Create. Open. Control.” to capture this perspective.
In essence, his point is this three verb synopsis seeks to:
(a.) usurp a competitive advantage that is not its own by adding its own strengths and values to the technology behind it;
(b) open the technology to others for their use and improvement for purposes of collective buy-in and development; and
(c) then pivot to an endgame where overwhelming financial power is used to dominate the theoretically open-source product.
While we start with a community based and open ‘standard’, over time it becomes effectively proprietary because the vast amount of development resources, functional realities (e.g., storage requirements), and ability to implement…all rest with a single player.
In this instance, that player is Google.
Outta Control
Why would you care? Well if you are a consumer of web content, you won’t.
But if you are a creator of content and in any way rely on that for more than a passing distraction, it is a problem. Whether initially intended or otherwise, the argument is AMP is a bold-faced power play by Google. Or as FerdyChristant.com points out, it is a loss of website sovereignty through the mechanism of pre-rendering.
“Pre-rendering” is search results content loaded on Google servers before you even click on a result.
The problem some have with this is that content is pulled from the source for the benefit of Google. The user need never leave the Google eco-system for his or her needs. That, and the fact that improved speed is less a function of AMP design and more of selective pre-rendering to game results for Google approved (AMP’d) websites versus non-AMP ones.
For the content creator, this means a loss of monetization in some instances, and can mean a loss of traffic or insight into traffic patterns.
Everybody Is Doing It…
Well what about adoption rates. Do you HAVE to get on the AMP bandwagon? According to link-assistant.com, possibly. In 2017 there were 0.9mm websites utilizing AMP. That increased to 31mm in 2018, and they extrapolate it would be 31mm in 2019.
But whatever the numbers, the reality is that as of April 2020, 0.1% of websites use AMP. per the World Wide Web Technology Surveys. Yes, that’s 1/10 of 1%.
One can readily argue, successfully, that it depends on WHO those websites are, not their total numbers. That is, for websites that generate large audiences and top rankings, AMP is central to success. And that for others who wish to grow traffic and ranking, they must follow suit.
So What Do You Do?
With all that said, I find it telling that such a small percentage of total ‘web flow’ is based on AMP. Like any standard, adoption rates matter, no matter who is driving those standards.
Remember Betamax vs. VHS? Sony was a behemoth. Ultimately it didn’t matter. And AMP is not showing a particularly strong hand in the percentage of site compliance.
I’ve Implemented AMP.
I’ve dealt with the wonky tagging system. I’ve accepted the stripping out of what was time consuming, and compliant frameworks to satisfy AMP’s draconian measures.
And in the past, I’ve largely been accepting of it because of the concept of opensource = fair play. But nope. At this point, I’m done with AMP.
I don’t like its limitations on design, its double talk when it comes to the basis for why it exists (psst…it’s about competitive advantage not speed), and where it places control – squarely away from creators.
It’s Not Going Anywhere
I would expect that one way or another AMP is here to stay.
In one reality…
It will simply rollover everyone in its path, demanding acquiescence, due to Google’s market share. With improvements in technology, allowable variation in website design and branding will return without sluggish bandwith demands.
But in this reality, it will remain a controlling factor for the web, under the Google umbrella.
In short, you will have the appearance of ‘variety’ website design, even on the mobile platform, but control and storage will be squarely in the realm of Google.
In the other reality…
It will become something watered down relative to its current Google-dominated design and compartmentalization. That is, it will survive and thrive because in this future it really will be AMP and not GoogleAMP.
And I’m happy to take another look when that second reality arrives.
(1) ferdychristant.com, “AMP: the missing controversy”.
(2) Luke Stevens – Twitter, ( @lukestevens, “AMP thread” ).