Why is amp bad?

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".

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.

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.

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.

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.

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

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.

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.

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

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).

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.

This is the weakest of all the complaints.

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.

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.

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.

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

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.

Because AMP strips content down to the bare bones and hosts it all within Google's server, everything starts to look alike. This means that you can have fake articles and phishing clickbait stories appear right beside legitimate news.

AMP — which stands for Accelerated Mobile Pages — was introduced by Google in October of 2015. AMP is an open-source custom web development framework created to speed up the loading time of web pages on mobile devices.

While the idea of having a faster mobile internet with content that loads instantly sounds like a great idea, there is a lot of concern among web developers when it comes to AMP. And these concerns should have publishers equally worried.

Here are just a few reasons why AMP is bad for both the webmasters and the web as a whole.

One of the problems with the Accelerated Mobile Pages concept is 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. This means that the reader is spending more time on Google’s site and will 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.

Just last month, Google stated that it is working on fixing this problem so that linked pages will appear under the original publisher’s URL.

Although AMP works with Google Analytics, you have to use a different tag, which can be quite time-consuming. If you don’t include the new tag, you miss out on a ton of analytics information.

Plus, AMP is not particularly easy when it comes to installation. You basically have to do all the coding manually. This puts you before a dilemma: either design your site the way you want it and the way it will convert, and set it up for AMP later, — or disregard conversion and aesthetics and make it an AMP site from the start.

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. You give up the overall styling of your page in return for a really quick download. 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.

Basically, Google is “forking” the web into a version of the internet that looks exactly like Google wants. The amount of tags is very limited, so most AMP pages have a very plain look — an custom web development becomes sort of an unrealistic and unnecessary field.

With more and more emphasis being placed on the damaging effects of fake news, AMP makes it even harder for readers to spot these types of stories. Because AMP strips content down to the bare bones and hosts it all within Google’s server, everything starts to look alike. This means that you can have fake articles and phishing clickbait stories appear right beside legitimate news.

In conclusion, while we can all agree on the fact that a faster mobile web experience is better for everyone — especially since the majority of web surfing is now done via mobile — the costs of implementing AMP may just be too high. If you have a well-designed responsive website with optimized images and video, you really don’t need to worry about AMP.

There are reports that Google is mostly pre-occupied with chasing their competition lately. Likewise, the AMP introduction seems to be Google chasing Facebook / Instagram / Messenger ecosystem: carousels, instant articles, stories. AMP works the same way to bring the content into Google’s properties: search result pages and Gmail.

Not everyone feels comfortable to give up their content and let it be served from Google’s cache. But not every webmaster acknowledges their choices!

Thing is, Google is pushing AMP adoption by their regular means of propaganda — “AMP sites will rank higher on Google!”. Moreover, a partnership with WordPress might bring AMP enabled by default to millions of unsuspecting webmasters.

As a result of AMP implementation, most web surfers won’t ever leave Google, since everything they search for will be served to them on Google’s “portal”. This is not really a “web” of interconnected websites anymore, but a centralized dystopia.

Further (and deeper!) reading on the subject, so that you can see I’m not the only one bashing AMP:

…And an impressive Twitter rant by a web developer @ activist Luke Stevens, read it all if you haven’t: