Removing Accelerated Mobile Pages (AMP)

Around 18 months ago I wrote a blog post called Accelerated Mobile Pages (AMP) (imaginative I know!) about implementing AMP into this very website. At the time it was purely out of curiosity. I happened to see a new navigation item pop up in the left hand panel of Webmaster Tools and thought I would give it a try. So why am I now removing it? I’ve listed a few of my reasons below.

Original Purpose

The purpose of Google AMP is to improve the user experience of the web. It does this by enforcing a strict standard on a set of custom elements. These custom elements can then be highly optimised for speed. Speed is the key selling point when adopting AMP. Pages across the web are becoming bloated and slow to load and this is becoming a real problem on mobile devices which have a limited resources and data available to them. Web sites in 2018 have more code, larger images, more ads, more of everything! I’m just glad I’m no longer on a 56K modem, can you imagine the frustration?!

Now I must admit AMP pages load really quickly and one reason for this is a browser will prerender the page before a user even clicks the link. This is really handy if you are on an intermittent connection (like on the tube for example). Need a page to read before you head into the next tunnel? Look for the AMP logo in the search results and it will already be there for you to read, no more data required (for the “above-the-fold” visible content). I hear you say “But that is awesome! What’s not to like?”. Well for me it all comes down the finer details.

AMP HTML implementation

The implementation wasn’t difficult, it was just a real pain to make sure everything was valid. I use a static site generator called Jekyll which allows me to easily host this blog on GitHub pages. Unfortunately, because you are rendering from Markdown and not handcrafting HTML, you don’t have 100% control over the HTML that comes out the other end. So if some HTML that is generated isn’t considered valid AMP HTML, you either have to find a hack or you are out of luck. No Google AMP Cache for you! I mention one of these issues in the original post around the use of Jekyll Rouge.


AMP is very (very) strict when it comes to JavaScript. No JavaScript to be served other than AMP JS. So no jQuery, no Bootstrap or Foundation, no nothing. The only JavaScript that is allowed to be served is AMP JS which is the library that powers AMP. Again note that it can only be served from Google, a self hosted version isn’t allowed.

So what is AMP JS? Well it is used to to transform the custom elements that Google has defined into elements that the browser understands. So why no other JavaScript allowed? Well the purpose stated is that to maximise page load speed, the browsers critical rendering path needs to be minimised. Adding other JavaScript will break this requirement if implemented incorrectly, so it is safer to remove all other JavaScript completely. Seems a little extreme! Is it true that AMP JS is all about speed? Not according to Maciej Cegłowski who rewrote the original AMP demo page without using AMP JS and it turned out to be much smaller and much quicker.

So it isn’t really about speed. I fear it is more to do with tracking and locking you into the ecosystem.

AMP Cache and validity

Once all your pages are valid you are good to go though… not quite. There have been a couple of occasions where I would see that a number of pages had suddenly become invalid due to the AMP specification changing. Now this isn’t a big deal in itself as the changes were fairly minor, but it does highlight the fact that you are essentially using a third-party product that is out of your control to display a large percentage of your website to your users, and what they say goes. In this case said third-party is Google, so what they really say goes!

For your content to be added to the AMP Cache it must validate. No exceptions. For a small site with a low number of pages like mine this isn’t a big deal. For websites with tens of thousands of pages, that’s potentially a lot of work! So if the specification changes and a 90% of your pages are suddenly invalid, best case scenario is it’s a quick 2 minute change to a template, or you could be trawling through hundreds of pages to make them revalidate.


Assuming you have taken the plunge and decided to adopt AMP, you are now essentially locked into the Google ecosystem. AMP is open source, but it is primarily driven by Google.

So you’ve decided to take the plunge and use AMP. Here’s what to expect:

  • loading AMP JS: the JavaScript that powers AMP. This can only be served from the Google servers, no self-hosting allowed.
  • to use AMP Cache: a lot of the speed gained from AMP is the fact that the pages will be served from a CDN; these CDN’s are run by Google.
  • a Google CDN URL when sharing content: Want to share a page you found that is using AMP with a friend? You will be most likely be sharing the Google CDN URL rather than content from the original author (NOTE: It looks like they fixed this very recently!).

So what do you get when you use all these Google technical toys? Well a big plus is you get preferential treatment from Google in terms of mobile search. Your content will be boosted up the search rankings above other content (on Google at least). Say you give it a try and realise it isn’t for you. How easy is it to remove? Well it might not be as simple as you think.

I think you get the idea. Google is fully in control of the bus, you’re just along for the ride.


I think the main thing I don’t like about AMP is the restrictions on JavaScript and CSS usage. Now I understand why those restrictions and specifications are so strictly enforced as they are performance best practices, but it takes some of the adventure out of being a Web Developer. I like being able to add random JavaScript functionality that doesn’t come pre-packaged in a toolkit. It is part of the fun. But then again maybe I’m just the wrong audience for AMP.

I fully admit I magnified my creativity restrictions problem because I went all out in my AMP usage. You have two options in AMP usage:

1) Lay your AMP website next to your standard website HTML so they both exist in tandem. 2) Go all out and use AMP HTML for all breakpoints and only have a single version.

I went for option 2. Had I decided to create two separate versions of the website this would have given me the creative freedom to add little bits of extra functionality here and there where needed. Which leads me onto the next oddity that I find unsettling…

Duplicate content

For years one of the key rules when it came to SEO was never duplicate content. It was SEO 101, if you duplicate content Google will penalise you. Google will assume the content has been copied from another website and rank you down into oblivion. Now suddenly we find ourselves duplicated all of our websites content and essentially maintaining two separate websites. To me that isn’t a good way to go, but maybe that’s just me and I’m starting to turn into an old man?


In conclusion I see why Google AMP exists and I understand what Google is trying to achieve (I think). I just don’t like the fact that it is locking you into the Google ecosystem and creating another “walled garden” on the web. Google is already the most powerful company on the internet and Google AMP is only going to increase their dominance.

What would be nice is if all Web Developers take the best practices that AMP promotes in minimising the browsers critical rendering path, and apply them to their current sites. That way we get a fast, decentralised open web that isn’t dominated by a single company. I wouldn’t hold your breath waiting for that to happen though!