AMP: the missing controversy

How Google cheats with performance

Introduction

AMP, Accelerated Mobile Pages, is a technology first launched in 2015 by Google. The main goal of the initiative is to drastically speed up the loading of web pages on mobile. Sorely needed, as the typical web page on slow 3G (a very typical network condition the world over) takes a long time to load.

So the goal in itself seems worthy. Yet the initiative has been met with lots of controversy over the years. I’m going to go briefly over these main points of controversy.

The main goal of this article though is to add a new point of controversy, one hardly discussed. The reason why AMP has instant performance.

First, let’s look at the other points of controversy.

Controversy #1: a new web “standard”

AMP has been created completely outside of W3C and WHATWG, the main standard bodies for the web. Standard bodies in which Google has a large, if not dominant presence.

AMP makes up its own standards that break with what is considered valid HTML. Case in point, have a look at how the AMP project’s homepage, which itself is an AMP page, produces over a 100 validation errors:

In AMP’s defense, despite it breaking the standard, browsers will render that page just fine because browser know how to deal with invalid HTML quite well. Because, well, pretty much every web page ever created is invalid HTML.

So this is merely a theoretical controversy. We have a shared web, governed by standards bodies. AMP ignores this reality.

Google’s main defense is that AMP is open source. Which isn’t just a weak defense, it’s no defense at all. I can open source a plan for genocide. The term “open source” is meaningless if the thing that is open source is harmful.

Controversy #2: loss of sovereignty of your website

One of the main implications of publishing an AMP page is that the page will be served from the Google domain. Or whoever is serving the AMP cache, yet mostly that will be Google.

This means less direct traffic on your origin, and more time spent at Google. Less traffic on your origin could mean less monetization opportunities. In general, it means less control of anything. You’re subject to whatever the AMP standard allows or disallows.

You’re giving up the sovereignty of your web site. Similar to when you publish all your content directly inside Facebook, you’re effectively losing all control of it now and in the future.

A simple defense here could be to just not use AMP. Ironically, AMP can actually increase traffic and drive better conversions. For the simple reason that it performs so much better than a normal web page. Hence, in the desperate race for traffic, organizations are lured towards AMP. The only price they have to pay is an almost complete loss of control over their web experience.

Build faster web pages then, and don’t use AMP? Even with this strategy, you cannot win from AMP’s performance. More on this in a minute.

Controversy #3: loss of diversity

On a diverse web, you would visit different origins, each having a different experience. Now compare this to Facebook, where every piece of content looks the same, coming from all over the web, yet flattened into a dull timeline. You don’t get to experience the home of that content, just the content itself.

This same effect of everything looking the same applies to AMP, in a lesser extend. In AMP’s defense, it’s possible to style an AMP page to fit your brand, yet there’s severe limitations in what you can and cannot do. Not just in styling, even more so in interactivity.

Controversy #4: performance

The items discussed above are not new, they’ve been discussed for years. So let us move on to the point of this article: the performance controversy of AMP. Which hardly is a topic of discussion it seems.

What we know about AMP is that the technical standard in itself enforces good performance. For example, CSS is limited to 50KB and only inline, custom JS is not allowed (other than via an iframe method), and all images are guaranteed to be lazy loading.

Hence, this is why AMP pages load instantly compared to a “normal” web page. It’s enforced by the standard. Right?

Wrong.

Let us look at a typical AMP page:

It’s an ordinary AMP page. I didn’t pick an intentionally bad example. We’re going to check the performance of this AMP page by directly measuring it from the origin itself (so not from AMP cache):

On webpagetest.org/easy (which preselects average 3G), the first meaningful paint is at 3.5s. A number that is not terrible in itself, pretty good actually, yet strangely far away from AMP’s typical instant performance.

Testing directly in Chrome, using “low-end mobile” and “mid-tier mobile” as presets (these slow down both the network and the CPU), we get 8.4s and 2.3s as first meaningful paint. Both aren’t close to instant performance, and 8.4s is just plain awful. This is an AMP page!?

Using a Lighthouse audit, the page fails to score on the good side of performance. Despite being fully valid AMP, a standard that enforces performance.

So whilst obviously the technical restrictions of the AMP standard help with performance, they are in no way responsible for having instant performance. Technically correct AMP pages will perform very similar to any non-horrible web page.

The difference between AMP performing instantly and getting numbers ranging from 2–8s as seen above have to be explained.

Part of that answer you can probably guess: the cache is simply very fast. It’s hard to compete with a Google-class CDN. I imagine thousands of servers strategically placed worldwide on the best connections available.

Yet this fast cache doesn’t explain a 2–8s difference. It hardly affects it. This is what does: