AMP, a Strategy
Post from July 5, 2018 (↻ August 16, 2018), filed under Web Development.
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 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.
Figure: Wine and meat, song and gay company just as AMP promises, too. (Copyright King Features Syndicate, Inc., distr. Bulls.)
About the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.