AMP, a Strategy

Published on July 5, 2018 (↻ November 27, 2023), filed under Development (RSS feed for all categories).

There are problems with AMP. They include whether a corporation or institution should incentivize site owners to focus on mobile performance, no matter the laudable goal; whether an artificial, in essence proprietary subset of web standards would be necessary or desirable to achieve such an aim; and how then lenient thresholds (like a “maximum” of 50 KB local CSS) would not allow for quite underperforming pages to conceal their still bloated nature. The AMP Letter includes popular criticism, my own concerns acknowledge our lack of an inside perspective.

Here’s my current (and as so often simplified) recommendation on how to deal with AMP, addressing any desire we ourselves or our clients may have to make use of it.

1. Avoid AMP

If you can, avoid AMP, and suggest your clients to avoid AMP, too. Apart from the many technical and tech-philosophical issues, we’ve had this kind of mobile special treatment a number of times by now: with WAP/WML around 2001–2003 and with dedicated mobile sites and domains from about 2006–2010. Each was a fad, each led to much costly extra work, and each failed. From my point of view, AMP is worst because it’s so arbitrary and forces, not solves, too many issues on everyone.

2. Use AMP Only (But Exclusively) for the Most Relevant Pages

When you cannot at all help it, implement AMP on those pages that need it, as a substitute for the standard HTML version. Indeed, don’t add an extra AMP page, but, with the silent assumption that, on desktop, an otherwise seamless experience is guaranteed, replace the page in question with an AMP one. This way you force yourself to focus and, with new pages, don’t end up building two possibly functionally very different pages in each case you decide to employ AMP.

3. Use AMP Only

If you must and really want to go all-in, then go all-in and build an AMP-only site. AMP works in every modern browser, so by using AMP from the get-go, you spare yourself from building and maintaining one and a half or quite possibly two websites instead of the one you really want to develop and maintain. Which is precisely what happened in the past and feeds the very first recommendation.

❧ AMP may or may not be around for longer than 2020, which is my estimate for its effective end of life. To encourage focus on mobile and speed I’m convinced we’ve had and have better means at our disposal than AMP. For mobile, search engines could indeed prefer those results that give a reasonable user experience. For speed, we could rather use one of the existing scales, whether Speed Index or PageSpeed or a mix of them, to encourage performance optimization—and to let site owners and developers decide on what to optimize exactly. (Google, in the meantime, could consider allowing everyone and everything to opt into using their cache.) Our standards landscape is already complex enough—it seems harmful to invent sub-standards to convolute that ecosystem even more. No matter the likely noble intentions, because from some angles, AMP is not a solution, but just another problem.

A late note, the same points about AMP can pretty much also be made about MIP and Turbo, too.

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m a frontend engineering leader and tech author/publisher. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m a contributor to several web standards, and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development (and engineering management), but also in other areas like philosophy. Here on meiert.com I share some of my experiences and views. (Please be critical, interpret charitably, and give feedback.)