Accelerated Mobile Pages, a Critical View

Published on August 18, 2016 (↻ July 1, 2023), filed under Web Development (RSS feed for all categories).

Disclaimer: As many of you know, I used to but don’t work for Google anymore.

Last year Google introduced AMP and the Accelerated Mobile Pages Project. Independent of suggesting tech paternalism when AMP gets treated preferably in search rankings, I’ve been concerned about what the AMP spec entails exactly. I’ll try to give my thoughts a constructive spin.

First of all, AMP tries to sell us things that are either already best or evidently bad practice. In the opening section of the spec, for example, AMP talks about optimization such as replacing image references with sized images, inlining images, inlining variables, preloading components, and minifying HTML and CSS. Replacing references, preloading, and minifying are best practice already; inlining is a good practice only when done automatically, otherwise unmaintainable malpractice.

AMP’s required markup comes off as clueless (I wish they had elaborated on their ideas to tell). @⚡ or @amp could have probably been done more humbly through something data-*. head and body are optional for (fortunate) reason and should stay optional (if you think about it, this requirement is backwards—AMP should rather insist on omitting all optional tags). A UTF encoding makes sense but the restriction needs explanation. Generally there’s no indication that everything had been done to avoid code bloat.

The AMP spec’s insisting on special or otherwise optional markup, metadata, and scripts rather seems to create and encourage such code bloat which, ironically, counters AMP’s objective to get to mobile pages that, per the FAQ, “load instantaneously.” Maybe this impression only manifests through the innocent omission of the team’s thinking, but making optional tags mandatory and giving already verbose social meta data a free pass appears all but speed-minded.

Other technical requirements like the prohibition of !important are entirely ill-advised, then. !important, for example, is part of the cascade and an important tool, and so AMP needs to yield here, not the whole world of web development.

AMP then manages to pull another trick that may hurt more than serve anyone: It demands too much and, with that, becomes too complicated. Duplication of content (in case of separate AMP pages); exceptions for HTML; exceptions for CSS; new code rules, components, templates, runtime, &c. pp. do not leave the impression that thought was on simplicity and making things easy for the user (developer), but on patching a great number of things to achieve a Google-internal and possibly Google-only objective (which would, of course, be ungoogley).

Lastly, and unless I overlooked something, AMP fails to explain why we could not have worked with a particular HTML mobile profile, similar to what was tried with CSS. The web standard specs suffer from excessive growth, and Google, swift as some of their teams may be, does not help us contain that situation. After all, the complexity AMP creates is something that will eventually fall on other people’s feet, but also hurt Google.

This leads me to my interim conclusion: Pending Google sharing their thinking behind AMP and the design decisions made, AMP looks like a shot from the hip that may have been addressed more appropriately by involving other mobile-related efforts, specs, and groups—or by simply defining criteria by which pages are considered fit for special featuring, thereby not interfering with specs and telling site owners how to write Google-style HTML. Both may make some roll their eyes, but if something’s worth doing then it’s worth doing well. AMP, the way it’s being presented to us, is not done well.

Update (June 25, 2017)

My prediction: By 2020 AMP will be dead (rightly so, without more insight into the strategic and technical decisions behind it). At the moment it’s just going to turn into a misguided bet that mostly non-Googlers will have to pay for.

About Me

I’m Jens, and I’m an engineering lead and author. I’ve worked as a technical lead for companies like Google and as an engineering manager for companies like Miro, I’m close to W3C and WHATWG, and I write and review books for O’Reilly and Frontend Dogma.

With my current move to Spain, I’m open to a new remote frontend leadership position. Feel free to review and refer my CV or LinkedIn profile.

I love trying things, not only in web development, but also in other areas like philosophy. Here on meiert.com I share some of my views and experiences.