Why AMP is not bad for your site and for the Web

Immortalised in a much-amplified 2018 Medium article "Why AMP is bad for your site and for the Web", itself a re-hash of a 2018 letter by "concerned developers", the idea of AMP (Accelerated Mobile Pages) as a malign force has been dispersed around the web for several years via popular platforms such as reddit.

People condemn it repeatedly, many with know direct knowledge of the technology, and if an AMP link is provided on reddit, others hurriedly provide a link to the original web page as if they are doing a community service. If asked why, they either repeat "AMP is bad" or cite the Medium article.

While I'm no great fan of the direction Google has been taking in the past few years, not much of this belief stands up to scrutiny, and nor does the article's author's case against AMP. I believe most of the assertions in the Medium article can be factually countered, and I intend to do so here.

I have, by the way, no dog in this fight. Having made my first corporate WAP site in 2000 though, I recognise some of the same misgivings that are expressed in the article - but I have also been working with AMP for a few years and note a significant number of factual errors, misunderstandings, and misrepresentations in that much-cited article.

Once the factual inaccuracies are removed, the article turns from a portent of doom into the author merely saying "I don't like AMP".

What is AMP?

Before going on to provide counterpoints to most of the article's assertions, I just want to explain in brief what AMP is.

The AMP project is prima facie an attempt to make the mobile browsing experience better for people using the limited bandwidth, limited-size screens, and slower hardware that are common to mobile browsers. It does this by using a stripped-down version of HTML with restricted iterations of JavaScript and CSS. 

AMP is an open source project that is being funded by Google and facilitated on Google hardware.

The alternative for displaying most web pages appropriately in a mobile browser is 'responsive design'. This very clever technique allows the same content to be recycled for both desktop and mobile browser, by hiding some elements, altering others, and sliding others around depending in the size of screen with which the page is being viewed.

The issue with responsive design is that the amount of code required to facilitate this slide-and-hide is pretty big for a web page - megabytes of code, in fact; furthermore the amount of underlying JavaScript allowable in a responsive page is essentially infinite, thus increasing rendering times over slow networks to snail-like speeds, or even causing the browser to time out. Providing a stripped-down, low-bandwidth alternative to full-fat web pages would be particularly valuable in developing countries and remote areas, by making information more easily accessible to those who have no alternative to a mobile browsing platform.

If you are in charge of a website, you can create AMP versions of your pages and offer them to the search engines by giving them a URL with an "/AMP/" coda at the end of your original URL. Example:

Original page https://romevacationtips.com/how-to-get-a-covid-test-in-rome/ vs the AMP version https://romevacationtips.com/how-to-get-a-covid-test-in-rome/amp/ (AMP pages can also be read in a desktop browser when on the originating site).

When indexing a site, Googlebot checks for this coda on each webpage it indexes and if it finds one, it stores it in the google AMP cache - thus the link above can be found on Google's own server at https://google.com/amp/s/romevacationtips.com/how-to-get-a-covid-test-in-rome/ as a search result only (note that you will be able to see the page at that URL only if you're using a mobile browser; Google will automatically redirect you to the original page if you try to view the cached version in a desktop browser).

When a search is carried out in Google on a mobile browser, the SERP (search engine results page) shows links to AMP pages where available. Clicking an AMP link in Google search results delivers the cached version of the AMP page to the mobile browser almost instantaneously because it was pre-loaded ("prerendered") by Google's cache when the SERP itself loaded. 

Most people managing websites achieve AMP compliance with a plugin that automatically follows the strict AMP coding rules, and outputs AMP versions of pages at the appropriate URL based on the user's chosen design, albeit with optional manual override for custom design and content, on a per-page basis.

What the AMP article gets wrong

The first thing that the author asserts that "content built utilizing AMP is served up through a cache on Google’s server rather than actually linking to the original page on a publisher’s website". So far so true.

First (misleading) assertion: Google steals visitor time

He goes on to say that "this means that the reader is spending more time on Google’s site" - technically true as well, but in practice what does this mean? The author of the web page is still in control of the AMP content, and crucially any "credit" that logging systems such as Google Analytics award to a web page for user behaviour thereon is also credited to the author of the page, not to Google. 

There's a link at the top of every AMP page that provides a clickable link back to the originating page and website, and all links within an AMP page go to the destinations requested by the page author.

Nothing is being stolen, so the complaint doesn't have any real meaning.

Second (incorrect) assertion: Google steals advertising revenue

According to the author, visitors will also "be seeing Google advertising as opposed to any paid advertising on the content provider’s site. More money for Google, less money for the actual content creator."

This is the first assertion that is absolutely, 100% false. No ads show up on an AMP page that aren't facilitated by an ad network account owned by the page owner. The only way Google advertising could display on an AMP would be if the page owner is participating in a Google-owned advertising network program, such as Google AdSense, but even if they are doing so, 100% of click-through revenue is awarded exclusively to the owner of the web page.

There is a critique to be made that AMP pages only offer access to a limited selection of advertising networks, which is limited by the JavaScript used to display ads: some advertising networks haven't yet decided to participate. But that isn't the critique being levelled.

Third (wildly exaggerated) assertion: there's a large technical overhead

The author goes on to make a couple more extremely weak assertions:

"Although AMP works with Google Analytics, you have to use a different tag, which can be quite time-consuming."

It takes me approximately 5 seconds to paste my Google Analytics UA number into the AMP plugin. That is the end of my technical involvement. If I were hard-coding my site it might take an extra 20 seconds to do a copy/paste across all AMP pages.

"If you don’t include the new tag, you miss out on a ton of analytics information."

AKA "if you make a mistake, it doesn't work." Yes, if you're building AMP pages you will want to include the new tag. If you don't include the new tag, you're not doing your job. This complaint is meaningless.

Fourth (unproven) assertion: Google is in control of your output

While Google's sticky fingers are indeed all over the project, Google doesn't control anything about content display.

"Because AMP is a stripped-down version of your original content, you are at Google’s mercy when it comes to how (and even if) your content is actually displayed."

That's not how it works. You're only at the mercy of the limitations of the open source AMP HTML, and your own skill therein. It's not just Google who uses AMP either (see below).

"You give up the overall styling of your page in return for a really quick download."

That's kind of the point. I was effectively styling pages with a similarly limited version of HTML back in 1997. The only limitation is yours as a designer.

Fifth (bizarre) assertion: it doesn't deliver video

This is the weakest of all the complaints.

"If your site features a lot of video, AMP would not be that beneficial for you as the download time would pretty much remain the same."

This makes no sense, since almost all video is embedded in web pages as an external call, and (unless it is set obnoxiously to autoplay) embedded video is by default an on-demand medium. The complaint here seems to be that AMP doesn't improve things enough. Which isn't a critique of AMP.

Sixth (misleading) assertion: it's proprietary

The next complaint is that AMP is a "fork" of current web standards. While again technically true, it actually appears to be a restriction in the current fork. As far as I can tell there's no new stuff in AMP, so this assertion is something of a red herring. (This is where I expect to receive brickbats, so do feel free to fire away in the comments.) He goes on to say that this "fork" is "exactly like Google wants".

This falls on its face because while Google is the godfather of the project, AMP is not Google's baby any more: it's open source and at the time of writing is being used by Bing, Baidu, Distributed Media Lab, Flipboard, Google, Ghost, Hatena, here on LinkedIn, Medium (oh the irony), Nuzzel, Pinterest, Reddit, Sogou, Tencent qZone, Twitter, Weibo, and Yahoo JP.

If it's an open-source "proprietary" standard, it's a corporate-agnostic one.

Seventh (completely misguided) assertion: it's limited

"The amount of tags is very limited, so most AMP pages have a very plain look"

I resisted derision until this point, but plainness is exactly the point: no bells and whistles = faster download. That's what it's supposed to do.

This is like complaining that your steak tartare isn't cooked enough.

Eighth (clutching at straws) assertion: AMP makes it "harder to spot fake news"

This one makes no sense at all. And nor does this:

"Because AMP strips content down to the bare bones and hosts it all within Google’s server, everything starts to look alike."

Sounds like the author hasn't actually used AMP himself. AMP is easily as comprehensive an iteration of HTML as it was in, say, 1998. See earlier comment about asserting brand with a limited design toolkit.

And this part of the author's complaint is the very thing that is at the heart of the W3C philosophy of divorcing content from appearance. You're not meant to include styling within the content - again, that's the point.

The final part of the article I won't address here as it's just opinion - one that I don't particularly agree with either - but it isn't factually incorrect, it's just him saying "I don't like AMP", which is totally fair enough.

What isn't fair enough is the wholly inaccurate foundation of the famous article, and people sharing it as if it's fact.

Jim Whittle is Professor of Digital Marketing at Rome Business School