Google AMP — why it was actually good
In October 2015, Google launched a thing called, initially, Accelerated Mobile Pages, or AMP for short. And web developers and internet prognosticators hated it.
It’s bad for your site and the web, it should be killed before it kills the web, it can go to hell, and it is (if you’ve not guessed) not a good thing, according to any number of frothing editorials on the web that you’ll find with a lazy Google.
These opinion pieces hated it for two main reasons:
- AMP delivered a cut-down, simplified version of the web and that’s bad
- Google was trying to re-invent the web, with Google proprietary elements
I’m not sure either of these was true.
Back in May 2015, Facebook launched a thing called Facebook Instant Articles. Delivered via Facebook’s API or an RSS feed, Facebook Instant Articles are delivered via a proprietary markup language, and are proprietary templates containing cut-down, simplified versions of news articles.
In September 2015, Apple joined in, with the launch of Apple News. It, too, is delivered via a proprietary feed (JSON, in this case), and it, too, is a cut-down, simplified version of a news article, using proprietary templates containing cut-down, simplified versions of news articles.
Google’s AMP, launched a month later, was different. It was based on allowlisted HTML tags: very opinionated HTML, but open HTML nonetheless. It didn’t need proprietary templates, and crucially, AMP was something that you could view in a normal web browser at the end of a normal web address.
Google’s vision wasn’t to produce yet another proprietary standard. It was, instead, to produce a version of HTML (with a JavaScript helper library) which was optimised for fast-loading by users, especially on mobile, and for search-engine crawling.
Google’s mistakes
Google made a number of mistakes with AMP; some of which have been significantly harmful for the project as a whole.
Mistake 1: its name
Accelerated Mobile Pages was a dumb name to call it: because AMP pages actually worked on everything. A fully-responsive website would work using the AMP framework just as well as a normal HTML one. Instead of being renamed, it took until 2019 for Google to pretend that it was just called AMP now, and not just a mobile thing any more. Google’s nothing if not consistently bad at marketing.
Mistake 2: Google did it
AMP was supposed to be an open standard; 30 companies were signed-up to it when it launched, with Twitter and Bing linking to AMP versions of webpages.
It was seen as a Google thing; when it should have been seen, perhaps, as an industry thing. As one Googler said: “I get a little bit irritated when sometimes people call it Google’s AMP, because it’s not … AMP was created as an open source initiative.” Mmmm. Sounds like a marketing issue again.
Google did devolve AMP away to its own open governance by the end of 2018. It didn’t help, though. And even today, the privacy policy of the AMP Project’s CDN still points to Google’s main privacy policy: leading many to believe that traffic from AMP pages were being used by Google to help target advertising and track users. I’m not sure they are; but the company has never made it clear. This is a missed opportunity.
Mistake 3: Google’s preference for AMP pages
Google decided that it would prefer AMP pages in search, and (though they never entirely said so) the inference was that AMP pages would appear higher than your competitors.
Google also required AMP pages in some products, like Google’s Discover feed (a list of web pages that you might be interested in). This was because AMP pages were easily spiderable, since they contained some standard metadata — not particularly because they were using “Google’s AMP”.
This was, however, more gasoline on the fire of anti-Google outrage. And perhaps it was a good idea for take-up; but it wasn’t a good idea for the project as a whole.
Mistake 4: it was promoted as an alternative
Google’s AMP team kept stressing that AMP pages were an alternative, and lesser, view to the proper webpage. You’d link to the AMP page from your real page, so that Google would know where to find the AMP page. This was catastrophic, since it communicated to web developers and the public alike that AMP was a secondary view, not capable of the functionality of a proper website.
In fact, the AMP framework is very capable of operating as your canonical website, and there were a number of benefits in doing so.
Unlike Instant Articles or Apple News, AMP was capable of running an entire website — news articles, yes, but also everything else you might want to publish: home pages, media-rich pages with audio players, shopping carts, or pretty well everything else you wanted to build.
The AMP project contained a number of useful building blocks and design features to make producing a website quicker and simpler. If you wanted to embed a Vimeo video, for example, it was two lines of code — one to pull in the Vimeo-AMP JavaScript component, and one to call it. Want to build a lightbox gallery? A date picker? A set of social share buttons? There are hundreds of components, all written and ready to use.
AMP dealt with responsive images automatically; could pull dynamic data in from APIs; and could do a surprising amount of things using built-in components, all built to be accessible and standards-compliant (after the JavaScript shim had done its thing).
AMP was also eminently cachable, and therefore could drastically speed up visits.
The most frustrating thing for some developers — that you couldn’t use your own JavaScript — was less of an issue once you realised that there was probably a component that let you do what you wanted to do anyway, or you could stick some interactivity into IFRAMEs; and in any case, the AMP team worked out a way of letting you use your own SCRIPT tags anyway (using a rather more secure method than normal HTML).
AMP-first websites (I ran plenty) didn’t have an HTML alternative: because the AMP framework was so capable, it was the website.
Google’s biggest mistake: the AMP cache
Google really complicated things by launching both Google AMP, but also the concept of the “AMP cache”.
The idea appeared to be that Google knows how to run very fast webservers, and publishers don’t.
So, to fix this, AMP was designed to be highly cacheable, and Google decided that it would cache copies of AMP pages on its own infrastructure. So, when searching Google, if you clicked on a webpage with the ⚡ symbol — meant to depict the speed you’d get with an AMP website — then that page would load from Google’s copy rather than from the publisher website.
This was messy. First, those pages would live under a Google URL, rather than the publisher’s. This was seen incredibly negatively by some: a misunderstanding that this would break your analytics (it didn’t), or was a lock-in to Google’s infrastructure. It wasn’t — you could use open standards to stop Google from caching your page anyway, and in fact, Bing and Cloudflare ran AMP caches as well as Google. We started seeing people sharing pages they’d found on the Google AMP cache, rather than the original addresses. This was undoubtedly bad.
The AMP cache confused and scared many people. In most cases, it wasn’t necessary: Google was pre-fetching web-pages anyway, so as you looked at Google search results working out which you would click on, your phone or computer was quietly downloading the pages into cache so they’d snap into view when you clicked into them. Their speed of loading was rather less of an issue than it needed to be.
But. After all that… AMP was a good thing.
What did AMP give us?
AMP was a very opinionated web framework. As one example, <img> tags wouldn’t work with AMP pages: you had to use <amp-img> tags. Why? Because images are the #1 thing that slows down a webpage - both slowing it down in loading, but also slowing down the user, as old-fashioned webpages jumped around as they loaded (known as a ‘layout shift’).
There’s no end of research pointing to speed on the web being one of the most frustrating things for users. AMP, undoubtedly, helped speed up the web: and got developers thinking about performance and removing layout shifts.
For this developer, AMP meant working out how best to cache the majority of webpages I display; and how to pull in more dynamic sections from that heavily-cached page using the amp-bind component (or a simple Javascript fetch command). I might not have to do this from Google’s cache; but I have to do it from my own anyway.
AMP’s creative use of IFRAMEs — where they could contain all manner of code, but the surrounding AMP-HTML page would still load quickly and performantly — helped many developers understand how to incorporate different data sources into their pages without slowing users down.
AMP’s inbuilt validation tool, visible to any developer in the console (or with a simple Chrome extension), caught any errors as you coded them, rather than any other time. The errors, albeit opinionated, were helpful and clear.
AMP wouldn’t work if anything wasn’t secure, using https; and it was, partially, responsible for many websites shifting to https to use it.
AMP didn’t like overly-complex ad code, either; since it was built for privacy and speed, it didn’t allow some of the more egregious abuses from the banner ads of the day. Most large ad companies built their own compliant AMP components anyway, so publishers were never locked into Google’s advertising solutions; but it did put some handcuffs onto some ad companies: to users’ benefit.
AMP also didn’t like websites that wanted to include random third-party JavaScript. And good. It’s a privacy nightmare as well as very bad for performance; so as a result, AMP pages were more secure, and more private, than others.
AMP pages were much, much smaller than the cruft-ridden pages that we had before. They loaded much, much faster; and the components had all been built with accessibility as a core feature, thus ensuring the right metadata was surrounding each component for screenreaders and other assisted technologies.
AMP’s early focus on mobile meant that developers also focused on mobile: and it’s one of the reasons why the web is now mostly usable on a mobile screen as well as desktop.
So — this is why I suggest that it was, actually, good for the web. Almost all the criticisms against AMP are unfounded; and AMP’s key offering — faster-loading, more-secure, more private webpages for everyone — seems to be a good one.
Why I moved away anyway
After all that — the reason I moved away from AMP might seem a little strange: it was slowing my website down.
Because of my time coding with AMP, I’d spent some time ensuring that my website would load quickly, with no layout shift. I’d done a lot of optimisation, and finally understood how caching worked.
It turned out that loading the AMP JavaScript shims — the required AMP JavaScript library and the separate AMP JavaScript components — was the bottleneck on the website’s performance. So, with the news that Google were no longer going to give preference to AMP pages anyway, I removed the code; and am now running AMP sensibilities without the AMP library.
Personally, I’d have liked to have self-hosted the AMP code (something the AMP team were very much against). It’s even possible now that having an AMP-accelerated website is against GDPR, much the same as Google Fonts is.
Why AMP saved the internet
As my own experience shows, we now live in a world where developers are striving for faster websites that are more private and more secure, smaller in bytesize, delivered to more devices than ever before.
This has been delivered in an open manner, using standard HTML and JavaScript: not by a second-tier of proprietary web products.
Much of AMP’s aims — no layout shift while loading, speed of loading being paramount, use of schema metadata, encrypted https as standard, accessibility being rewarded with higher placements, etc — are now built into SEO rules from Google and other search engines: not, perhaps, as part of a suggested framework, but merely as part of “this is how the web should be these days”.
That’s a good place to be; and AMP was — and still is — responsible for a lot of it.
AMP may well have saved the internet.