Development overhead

When most engineers write a site using AMP, they create a separate stripped down version of their page, utilising AMP-specific features. While that’ll lead to the best results, I'm just one woman; I don't want to double the effort of any modifications to my personal site that I work on in my spare time. What I instead did, was make use of the Gatsby plugin gatsby-plugin-google-amp. While there are a fair few AMP plugins for Gatsby, I found this one easiest to maintain. While other plugins promised a much more automated setup, I found none of them produced valid AMP pages that reliably recreated the original content. I wrapped the Gatsby createPage function to generate an AMP variant and passed in some context to tell the page that it's an AMP page. Whenever something wasn't AMP compatible, I'd switch it out using the context.

This was all well and good, but as I started adding more complicated features to my blog, such as a floating table of contents and share box, maintaining an AMP variant became difficult. AMP luckily has a component called amp-social-share which I could switch out most of my share bar for, with only a minorly different feel for the user. However, I encountered major problems when using gatsby-plugin-image, Gatsby's automatic image optimisation plugin. Every time I updated that plugin, it felt like a different thing broke. By the end, I had a patch file hundreds of lines long just to get valid AMP page output.

While my example above is reasonably specific to Gatsby and the setup I had, short of creating a separate AMP site, no matter how you set it up you'll likely run into some form of these complexities.

Analytics

I did not trust any analytics data that had touched AMP pages. I'm unsure if this was an issue in my setup, but even in that case, it's another added complexity to solve when using AMP. My Google Analytics data for AMP users would always feel wildly inconsistent compared to other metrics I had, such as the number of users who'd clicked my site from "Discover", a system that was AMP-only at that time. I also noticed many cases of users on an AMP page who then clicked a link on the site, taking them out of AMP. These instances would always be marked as two separate users, inflating my user count on the analytics. In fact, since removing AMP, I've noticed my user counts are significantly more stable day to day, as well as slightly higher. This finding is, of course, just correlation; we can't draw any real conclusions from that.

AMP Pages are safe to remove

When I heard the news that any site could access the Google features previously hidden behind AMP, the biggest concern I had was whether removing the pages would temporarily confuse Google and damage my SEO. After a particularly painful AMP-related problem while updating dependencies, I took the plunge. And... everything was fine? After removing the pages, I noticed no issues on Google Search Console and no drop in traffic. The traffic that previously used AMP was just all served normally.

In saying this, I did take extra special care to remove all mention of AMP from my site. In particular, I ensured that no amphtml link tags existed on my site. My experience doesn't mean it's impossible for removing AMP to cause an issue, but it looks to be perfectly safe if done cleanly.

AMP is slow

Once I removed AMP, my average page load times actually improved. I'm sure I could have optimised my AMP pages more, or maybe my non-AMP site was more optimised than what Google used as a comparison benchmark for AMP. Either way, keeping AMP around was a detriment to the user experience, not an improvement. Sadly, this is not an uncommon occurrence.