Google AMP lowered our page speed, and there's no choice but to use it

This is part of a series of articles on the repercussions of AMP adoption. AMP is being given special attention due to its potential to centralize control of the way the web is built. Read more: The hoops you’ll have to jump through to use your domain with AMP

For those that don’t know, a very quick primer. AMP is a set of rules that publishers - typically news and analysis content providers - must abide by in order to appear in the “Top Stories” section of Google’s search results, a lucrative position at the top of the page. It’s also required for your content to appear as a “rich” result, meaning emphasized links with images, which can receive a lot more attention from users. AMP must be implemented by the publisher on their site, and it’s not trivial.

Google puts the onus on publishers to rejig large tracts of their website’s layout, content, and functionality, in return for preferential treatment. Google promotes AMP as a way to make websites faster. That’s supposed to be the primary benefit, and the reason Google is pushing AMP so forcefully.

AMP can make your site slower

We here at unlike kinds decided that we had to implement Google AMP. We have to be in the Top Stories section because otherwise we’re punted down the page and away from potential readers. We didn’t really want to; our site is already fast because we made it fast, largely with a combination of clever caching and minimal code. But hey, maybe AMP would speed things up. Maybe Google’s new future is bright.

It isn’t. According to Google’s own Page Speed Insights audit (which Google recommends to check your performance), the AMP version of articles got an average performance score of 87. The non-AMP versions? 95. (Note: I updated these numbers recently with an average after running the test 6 times per version.)

Update: Here’s data from a performance test that ran 9 times for each version of the page: AMP, non-AMP

The mean time to first byte for the AMP page is 1005ms, and for non-AMP it’s 989ms. So the server renders the AMP page 16ms slower, or 1.6%. This is a tiny amount, but is it enough to explain the discrepancy?

The time until the page is visually complete for AMP is 2166ms, and for non-AMP it’s 1955ms, which is a difference of 211ms or 9.7%, a much larger discrepancy than that on the server-side. Also, I suspect the server difference might be because the AMP version needs to inline 50kB of CSS in the HTML, while the non-AMP version just links to an external file. This is an AMP requirement.

Mind you, the AMP versions are hobbled - unauthorised javascript interaction is forbidden by Google, so you can’t vote or comment in place - it’ll kick you to the full version of the page. This is the fruit of weeks of labour converting the site: a slower, less interactive, more clunky site.

Google doesn’t need AMP to rank pages by speed

But maybe this humble publication is so darn well made, our coders’ abilities so incredible, that when you consider all the slow sites out there, the greater good is served by bringing all sites up to scratch, performance-wise, even if fast sites are forced to slow down.

But Google already ranks websites by speed. This tells us that every crawled site’s performance is measured in some way that Google finds accurate enough to use for a site’s ranking - you know, the position on Google’s results that can literally mean the difference between a failed business and one that makes millions of dollars, that an $80 billion industry is built upon.

So you’d imagine that Google’s existing page speed ranking could easily be used to limit which sites appear in the carousel. Anything with a performance score below an 80 could appear as a performance issue in Google Search Console, and the site demoted.

But no, Google insists you build your website with their technology.

AMP isn’t about speed. It’s about control.

AMP is an open source project. That evokes images of open, honest, collaboration amongst equals. But that’s not what’s happening. For a start, anyone contributing to AMP is required to sign a contributor license agreement (CLA) for their code to be accepted into the project. The CLA requires that you “grant to Google and to recipients of software distributed by Google a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license”. There’s also a clause for much the same regarding any patents. Note, you don’t grant these rights to the AMP Project, you grant them to Google. Google owns the code and patents.

The issues on AMP’s GitHub page is littered with revolts. Most notorious was Google’s attempt to co-opt email itself. The issue is full of non-Google developers in open revolt against Google’s power-grab, with users describing it as misguided and user-hostile, complete with frequent use of the thumbs-down emoji. Google’s response? They’ve labeled the issue Priority 2: “Soon” and “INTENT TO IMPLEMENT”, and are powering ahead regardless.

Then there’s users begging Google to allow them to use more than 50kb of CSS. Yes, most site’s CSS is bloated. But 50kb is an absurdly small, arbitrary limit. Stylesheets these days handle resets for normalising behaviour between browsers, grid systems so you can lay things out without resorting to murder-suicide, and responsive queries so that your site looks great on mobile and desktop (and tablet and landscape and Android and iPhone.) These essential components will take you a decent way to to the 50kb already. If you’re looking to create an advanced layout or something unique and attractive, you’re shit out of luck.

Google’s own websites and apps are infamously bloated with CSS and JavaScript creating advanced layouts and interactivity, so you can imagine they think interactive or uniquely designed websites are worth the kilobytes. But customizability is for them, not for you. Publishers are limited to a meagre set of bundled components. If you believe in a web that’s beautiful with distinctive websites full of personality, it’s like trying to make an intricate sculpture out of Legos.

As an example, you’re limited to using Google’s lightbox implementation. This component won’t let you allow users to close it by tapping on the image itself, instead they have to tap a black area around the image. It goes against the conventions established by other sites on the web, so users will inevitably struggle with it, as it behaves in a way that they won’t expect. And if you want something really nice for users, like scrolling up to dismiss the lightbox? Google says no. No javascript. Only components. Want to add a dark mode button? Google says no.

This is the core of the problem. If you’re trying to build a brand with something unique or distinctive, Google forbids you. And let’s not forget, it’ll be served from a Google domain, further diminishing your brand.

Sure you can build 2 sites, one AMP, one non-AMP. But it won’t help. Instead you’ll confuse your users (and certainly not entice them) with links like “visit the full version of the site to comment”. Google even encourages publishers to make one version of their site. An AMP version. An internet where every publisher is using the same 30 components controlled by one company? No thanks.

Google’s strong-arming the media

Google’s in an incredible position of power. According to the Wall Street Journal: Publishers who are critical of AMP were reluctant to speak publicly about their frustrations, or to remove their AMP content. One executive said he would not comment on the record for fear that Google might “turn some knob that hurts the company.”

Sure, there’s a technical steering committee. 3/7 of them are Google employees, and the others are platforms: Microsoft, Twitter, Pinterest, and Pantheon (a web host, for some reason) - not the people actually making the content. Not the publishers like the New York Times, just the gatekeepers.

Why can Google do this?

Because they own the web. The top positions on Google’s results pages are highly lucrative. If you want to build a business around a website, you need to be up there. If you’re publishing news, you need to be in that Top Stories section. You can’t rely on hits from DuckDuckGo or Bing, you need Google. They own the web as much as they own Android’s Play Store. But at least on mobile you’ve got the option of choosing iPhone. For the web? You don’t. It’s only Google.

From instant answers where users read content scraped from your site without visiting it, to Google assistant reading your site with barely a nod in your direction, to AMP with plain, samey sites served on different coloured paper, and from a Google domain no less, they want people to visit Google. Not your site. Your site just feeds Google. All these recent initiatives see users consuming your content without even visiting your domain, and in some cases, without seeing your ads or your pleas to subscribe.

If Google’s users were all served by scraped content in Instant Answers and Assistant answers, and dull, non-interactive websites served from Google’s domain, publishers become nothing more than a dumb pipe. But unlike ISPs, no one’s paying them.

Updated 2019-04-12 to include more performance test data and an explanation