In October 2015 Google unveiled an HTML-like markup language project called Accelerated Mobile Pages (AMP) with the intent to make the internet faster. AMP would load webpages more quickly, particularly focussing on mobile devices, the company promised, and, like some of their other projects, Google made AMP open-source. While the intention seems great on the outside, and while we can all benefit from a faster web, the execution was dangerous: besides a set of custom tags AMP relied heavily on caching and serving webpages from Google’s servers, automatically (and often inelegantly) stripping some data in the process and generally taking away visual and functional control from the owners of those webpages. Worse still, users who clicked on Google search results would be delivered AMP-driven webpages whether they wanted it or not. As of August 2019, there is still no way to turn this off.
Alex Russell was one of the first people to speak out against AMP back in 2016, less than a year after AMP was launched. Back then he wrote about how Google might be stealing website traffic by delivering cached, AMP-driven pages from their servers; and there is reason to believe his intervention may have pushed Google to prioritise adding the ‘View original’ button that today has taken a step back to become a more inconspicuous ⓘ icon. Users need to click on this and then on a link shown in grey next to a more catchy, blue ‘More info about AMP’ link (see picture).
AMP casually disfigures the web
AMP delivers a mediocre web. Given that nearly everyone uses Google as an awkward launchpad (including those who first look up the word ‘Google’ on their address bar only to open a Google search page with results for the term ‘Google’ and then erase the search field and repopulate it with their actual search term) the use of AMP is simply skewing people’s experience of the web and helping Google create a monopoly. Look at the following two versions of a BBC article, keeping in mind that BBC specifically supports AMP on their website:
On the left is the BBC webpage as BBC intends it to look; on the right is the webpage as AMP renders it. While there are huge differences between the two let us go over just the ten most obvious ones:
- There is additional padding around the whole page (the white border you see on AMP) and—as anyone with any experience at all in web design will tell you—this can potentially mess up page layouts making webpages look on your device like they actually would on much smaller devices.
- The sharing options are out of place on AMP.
- The ‘Entertainment & Arts’ category link is at the top on BBC but AMP puts it next to the date and restyles it.
- The clock next to the date is misaligned on AMP.
- The cover image caption has some rather ugly additional padding.
- The byline is restyled.
- The top menu bar (BBC/Log in/Home/News/More) is gone, and in its place is the AMP bar with a redundant share button.
- The page does not respect native scroll behaviour with the address bar and bottom bar both in place while scrolling rather than giving way to a beautifully immersive fullscreen experience like Safari does by default.
- Hitting the status bar while on an AMP page does not scroll to top. This is not something visible in screenshots, but it is another example of AMP disobeying native operating system behaviour.
- The URI on the BBC webpage is bbc.com while on AMP we are viewing the contents of bbc.com while not actually being on that site: we are on google.com instead.
- I know I said ten but let us throw in a bonus observation while we are listing things: AMP completely blocks off Safari webpage search. Oh, yes, it is that ridiculous.
The question that remains is, given all the mess and trade offs with AMP, is the two seconds quicker page load time worth it? To me, it clearly is not. I would rather read peacefully as BBC intended. I would just as eagerly hope that my readers view essays and other writings on my website the way I intended it after careful, precise designing. John Gruber calls this ‘publication independence’ (more on this below).
Keep in mind, though, that in the example above the BBC opted into AMP—probably because search result carousels (and search results in general, probably) prioritise AMP-powered links. This makes sense for news websites but makes no sense whatsoever for all sites on the web. Delivering all webpages on AMP is like going into an upscale restaurant and having the chef toss some stuff carelessly onto your plate and tossing it on your table with sauce spilling from the side because, well, you have the same ingredients after all, plus they served it faster. Faster is not always better as Alex puts it:
I don’t know why I do it, but for some reason it just doesn’t feel “right” to me to consume the content through the AMP. It feels slightly off, and I want the real deal even if it takes a few seconds extra to load.
On the one hand Google gives publishers the option to implement AMP if they like it (I, for example, have not and will not do so—nor will Alex and lots of other website owners) but on the other they give users no option to disable it. This makes no sense whatsoever: why deliver mediocre solutions and do so forcibly?
Well-developed websites can make AMP meaningless
John Gruber pointed out rather blatantly back in mid-2017 that ‘Google has no respect for the platform. If I had my way, Mobile Safari would refuse to render AMP pages. It’s a deliberate effort by Google to break the open web.’ Honestly, AMP deserves more caustic criticism than this, and Gruber delivers:
I’m on the record as being strongly opposed to AMP simply on the grounds of publication independence. I’d stand by that even if the implementation were great. But the implementation is not great — it’s terrible. Yes, AMP pages load fast, but you don’t need AMP for fast-loading web pages. If you are a publisher and your web pages don’t load fast, the sane solution is to fix your f—ing website so that pages load fast, not to throw your hands up in the air and implement AMP.
The trouble, as I said earlier, is not for individual website owners but publishers. As an individual, my website is wholly under my hands and is not driven by publicity rather by relevance. However, for publishers and commercial websites ranking high on Google search results can make or break their business. BBC is a publisher much like TNW, and they both rely AMP. The bad news is not that they opted into AMP but that the option is not what it seems: publishers not opting into AMP not only fall in search rankings but also lose a place on the news carousel at the top of search results. By forcing AMP—indirectly on publishers and directly on consumers—Google is fundamentally changing the nature of interactions on the web. And this is change for the worse.
Google’s walled garden
Earlier that same year Kyle Schreiber wrote about how AMP is really a cheap shot from Google as it tries to lock publishers into its own standards, controlled by its own team of employees who call the shots even as the AMP project itself masquerades as an open-source initiative:
Make no mistake. AMP is about lock-in for Google. AMP is meant to keep publishers tied to Google. Clicking on an AMP link feels like you never even leave the search page, and links to AMP content are displayed prominently in Google’s news carousel. This is their response to…Facebook and Apple… However, Google’s implementation of AMP is more broad and far reaching than the Apple and Facebook equivalents. Google’s implementation of AMP is on the open web and isn’t limited to just an app like Facebook or Apple.
…Google already makes deleting AMP pages difficult. Despite touting AMP HTML as an open standard, every one of the AMP Project’s core developers appears to be a Google employee…This keeps the AMP HTML specification squarely in the hands of Google, who will be able to take it in any direction that they see fit without input from the community at large. This guise of openness is perhaps even worse than the Apple News Format, which at the very least does not pretend to be an open standard.
This was all back in 2017. The following year, around February 2018, Google came out and said as much at AMP Conf 2018. Barry Adams on Polemic Digital points out how much of an open secret Google has made this seem:
Google doesn’t quite come out and say this explicitly, but they’ve been hinting at it for quite a while. It was part of the discussion at AMP Conf 2018 in Amsterdam, and these latest Search Console messages are not-so-subtle hints at publishers: fully embracing AMP as the default front-end codebase for their websites is the path of least resistance.
That’s what Google wants. They want websites to become fully AMP, every page AMP compliant and adhering to the limitations of the AMP standard.
That is the problem: Google wants to push aside an open, well-established standard like HTML and force users into slowly switching to its AMP code. This will let Google control every nook and cranny of a user’s experience on the web. After all straightening things out and presenting pieces of the web in a seemingly organised manner has been what Google Search has been since day one. AMP is then like Google on steroids. AMP will allow Google to crawl sites better and make future changes more easily, all on Google’s own servers since it is from there that AMP webpages are served.
AMP is a bane to the web and has the potential to undo its open nature by slowly and methodically taking it over, one website at a time. Most content-heavy sites can be read on Safari reader view (I am sure other browsers offer equivalent options) without waiting for the entire page to load, and most websites in general can benefit from better code that can make webpage rendering quicker.
As a publisher, I have disabled AMP on this site and still find that webpages load quickly enough. As a user, Google, to me, is on its way out: I have already started using DuckDuckGo as my default search engine across all my devices and have had no regrets for the past six months. In today’s world of privacy scarcity and monopolies by tech companies famously devoid of humanity, DuckDuckGo makes a splendid case for itself. The web will be safer to a good extent again the day AMP is shuttered, but that, unfortunately, does not seem to be in Google’s best interests and such a day is nowhere in sight; the AMP lightning symbol, though, has started becoming an eyesore. If more websites take Google up on AMP there will soon come a day when we search on Google, visit a result on Google (via AMP) never leaving the search engine and going to another website. The internet will not be a web anymore. The internet will be centralised and the old joke about Google being the internet will come true and it will not be as funny anymore.