Why I deactivated AMP and Instant Articles

It’s all about control, user experience — and good old fashioned frustration.

Since October last year I’ve been experimenting with Facebook’s Instant Articles format and Google’s Accelerated Mobile Pages (AMP) on my website/blog, Medieblogger.dk.

Both formats aim to give users a faster load on the mobile phone, but they do it in different ways. Instant Articles only work in Facebook’s app, while AMP is a web format, that can exist next to (or instead of) your normal website.

But now I’ve decided to stop and go back to just having a website. Here’s why:

1) Instant Articles

My biggest issues are with AMP, but let’s start off with Instant Articles.

Recently I finished reading Walter Isaacson’s Steve Jobs biography. One of the things, Jobs cared about (a lot) was having complete control over the user experience. This is why you don’t find Mac and iOS operation systems on other units, just as you won’t find other operating system on Apple units.

Now, I know I’m no Steve Jobs, but I get the point about having control over the user experience. You don’t really have that with Instant Articles. Sure, you can have separate rules, but it almost looked like a Facebook form of settings and rules that had to be set up — and even if you did all that, I’d still question how effective it was. I still think that all Instant Articles look alike.

When I choose a new design (or ‘theme’ as it’s called when you are using WordPress to publish) which I did recently I put immense weight on the reading experience, both on desktop computers and mobile phones. It might be the column width, the text size, font or something else that needs some tweaks. If I want some consistency across web and the Facebook app I would have to get these tweaks and changes into Instant Articles.

By not having Instant Articles I don’t need to do these things. Okay, the articles load slower and that makes for a potentially poorer user experience, but it gives the users the experience I can vouch for, so to speak. If Facebook all of a sudden decide that links should have a different color or that blockquotes should be shown in another font or have a background color, I am subject to that — whether I like it or not.

Instead, I choose to live with longer load times — and maybe a WordPress website without a ton of plugins isn’t the biggest performance hog in the world.

Another thing I don’t like about Instant Articles (and which I have written about before) is that it introduces another stream of comments to moderate [Medieblogger (in Danish)]. This means that if two people reading the same article each write a comment om the same article on my website and the Instant Articles version, they won’t see each other’s comments. To me, that was a strong argument in favor of having only one version of the content.

Also, there are two “layers” in Instant Articles. There is the content itself (the Instant Article) and the post(s) where the article is shared. These are two different types of objects, so if someone likes or reacts to (or comments on) one object (for instance the post on my website’s Facebook page sharing the Instant Article) it won’t show up on the other object.

Again, I’m sure Facebook has good reasons for this — after all, it’s fair enough that if Person X shares my article and Person X’s friend, Person Y, write a comment, I can’t see that comment. This is the way sharing on Facebook works today but for some reason it annoys me that Instant Articles work in the same way. Maybe, if the user could comment on a post sharing an Instant Article and allow the comment to be included on the Instant Article itself..? Because it fragments the conversation. Content can be commented and interacted with multiple places:

  • The original website
  • The Instant Articles version
  • The share post (on my website’s Facebook page and other posts)

Here I chose to cut out the Instant Articles layer.

2) Accelerated Mobile Pages (AMP)

My frustrations with AMP are somewhat similar to what I’ve mentioned above — and then there’s some added frustration on top of that. Plenty. My problems with AMP can really be summed up in one sentence: AMP is trash.

First, let’s take a look at what AMP really is.

2.1) A kind of HTML

AMP is a separate language like HTML, which many websites on the internet are created/written in. Here, AMP makes three mistakes:

  1. It uses its own tags, which means that you write <amp-img> instead of <img> which is downright silly.
  2. You have to call a script (from Googles ‘content delivery network’) in order to get AMP to work. The script prioritizes the load of the web page, for example it makes sure that elements like images aren’t loaded until right before they are to be shown. This create a dependency in an otherwise ‘open’ format. The AMP team probably have their reasons for this, but for those of us implementing AMP it could at least have made more sense if you could include the script in your existing HTML, which then would get its load optimized.
  3. The content is cached at and retrieved from Google’s servers; the so-called ‘AMP Cache’. This introduces some serious issues:

2.2) The user experience

This is a part of AMP that has been criticized quite a lot recently. Much of the traffic on AMP-optimized pages are referred from Google search results. Google has even begun highlighting AMP pages in the search results (like Facebook marks Instant Articles with a small lightning in the app), and it loads amazingly fast — because Google loads the content from the Google domain, where the search results are.

What this means is that the user is looking at the content on google.com (or some other Google domain) and not the website where the content is actually coming from. It also affects the user experience. First, the page scroll gets worse and you can’t search on the page in Safari on iPhone. Originally you have to manually remove the Google domain from the URL in the browser’s address bar to get to the original page, but Google has since (probably due to public demands) included a link-button which can get you there much easier.

But it’s still less than ideal.

Besides that, AMP has some weird limitations. Among other things, you can’t have forms. This means that you can’t get people to log in or sign up for your newsletter in the AMP version. (This may have been improved later, but I couldn’t get a simple text input field through the AMP cutter…)

I only really started paying attention to all of this when I read John Gruber’s post on Daring Fireball:

But other than loading fast, AMP sucks. It implements its own scrolling behavior on iOS, which feels unnatural, and even worse, it breaks the decade-old system-wide iOS behavior of being able to tap the status bar to scroll to the top of any scrollable view. AMP also completely breaks Safari’s ability to search for text on a page (via the “Find on Page” action in the sharing sheet). Google has no respect for the platform. If I had my way, Mobile Safari would refuse to render AMP pages. It’s a deliberate effort by Google to break the open web.

Gruber links to this The Register article, which has a fair amount of criticism of AMP — and has links to other articles like it. I agree, this is not good enough — to put it kindly.

I didn’t decide to turn off AMP, though, until Twitter all of a sudden started linking to AMP pages. This happened without any announcement; it just happened. For some reason I chose to live with it in the Google search results…as I mentioned AMP pages load pretty damn fast from those search results, so I decided to carry on with the experiment…

But Twitter is different. It links to the AMP version of an article (the URL address followed by ‘/amp/’) which, in a way I haven’t quite figured out yet, is pulled from Google’s servers. Here the load improvement is less significant than from Google’s search results — which means there is less reason to use AMP.

I used the ‘original’ AMP plugin for WordPress, built by Automattic, the company behind WordPress. At the time I’m writing this that plugin hasn’t been updated in nine months…

Maybe there are better plugins out there, but I chose to use the one I trusted the most. However, it offers almost no customization (I can, as far as I can recall only switch between a light and a dark theme) and not only isn’t the design pretty — it’s only partially translated. For instance, if you were reading an article published two hours earlier, it would say “To timer ago” (“to timer” is Danish for “two hours”). That is somewhat not cool.

Here we are also touching on some of the things that annoyed me in Instant Articles: That I have to make all kinds of tweaks (provided that I actually find a plugin that allows me to change anything) to change the design and reading experience into something of my liking.

I am sure there are WordPress themes out there supporting AMP (I know there are) but the theme I’m currently using doesn’t — so that doesn’t really change anything. But it’s worth considering if you want AMP on a WordPress-powered website.

2.3) Getting out of AMP

This is where it gets ugly…

I deactivated the AMP plugin in WordPress and all was well. Until I later tha day pressed a link in the Twitter app pointing to an article on my website. I got a 404 error page (“not found”), which made no sense to me; the website was working the way it was supposed to.

Then I discovered the problem: Twitter was linking to the AMP version (where the URL adress has ‘/amp/’ appended) and this didn’t exist anymore. It was the same with search results, which still showed the cached version; it was only a matter of time before that would run out and error pages would be displayed here as well.

So, by deactivating the official WordPress AMP plugin I rendered my website close to useless in the Twitter app and Google’s search result. Pretty annoying.

I did, however, find a solution. I had to install a plugin allowing me to redirect the traffic to the ‘/amp/’ pages to the original URL address. This is (if you ask me) a less than ideal way to do it, but it solved my problem; Twitter links started working again.

But if you click on a search result pointing to my website you get a Google 404 “not found” error, because the Google-cached AMP page no longer exists:

Google’s error page… on behalf of my website

This is — so say the very least — incredibly annoying, even though there is a link taking the user further, to my page, which is still there. I guess I have to wait for Google to re-index these articles to find out that they are no longer AMP optimized. This is not a problem with the articles published after I deactivated AMP and others might not react as mildly to this as I do after all…

It’s actually pretty crazy when you think about it… Until Google re-index the articles in question, I have to live with the fact that it’s Google’s error page that is being shows — not my own, so I at the very least could inform the user why he/she is looking at an error page and that the content is still available.

As I read in a Google Group thread:

Dont think Google are expecting anyone to want to turn AMP off :)
You can be the guinea pig.

This article was originally published (in Danish) on Medieblogger.dk »