Accelerated Mobile Pages, a Critical View
Published on AugĀ 18, 2016 (updated JulĀ 1, 2023), filed under development (feed). (Share this on Mastodon orĀ Bluesky?)
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 (long: Jens Oliver Meiert), and Iām a web developer, manager, and author. Iāve been working as a technical lead and engineering manager for companies youāve never heard of and companies you use every day, Iām an occasional contributor to web standards (like HTML, CSS, WCAG), 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. (I value you being critical, interpreting charitably, and giving feedback.)