Web Development

Thinking about AMP? Think twice.

January 07, 2020 7 min reading time

Google’s AMP (Accelerated Mobile Pages) has been a topic of hot debate over the last few years, with some fans and many detractors. For those who don’t know, AMP is a collection of existing technologies put forth by Google in an effort to speed up the mobile experience on Google. To encourage its use, using it on your website means a small boost in your search engine rankings. Sounds like a great thing, right? So where are those detractors coming from? Well, there are some problems with AMP, which are well known in the web development circles but rarely discussed in marketing circles. Many developers are taking a stance on this. Here are a few things to consider before making a move to implement AMP on your web content.

AMP means giving your content to Google

This is probably the biggest difference to grasp. To implement AMP on your website, you’re not just optimizing your content. You’re giving Google a copy of your content to serve up to mobile users. This means that mobile users who want to view your content will no longer go to your website—they’ll go to Google’s version of it. It sounds like a subtle difference, but there are some big implications with this.

One, Google will determine how to serve up your content. You may have things like redirects and dynamic content on your site. You may have put some things in place on your server to run before content is served up. Google may not honor those. What’s more, AMP is always changing, so even if something is working now, there’s no guarantee that what’s working now won’t be taken away with the next update.

Two, Google eliminates the middleman and serves up your content without users actually going to your site. AMP-optimized content shows up in a carousel at the top of Google search results with an excerpt of the content in question, which theoretically drives more traffic to the content. Except that it doesn’t always do that. There are many cases where users just read the excerpted content on the Google search results page and never visit the actual page the content is hosted on—something previously impossible.

Three, since content is hosted on Google’s site not yours, even if a mobile users goes to Google’s copy of your page, if they choose to share the link with others, they’ll be sharing the link to Google’s page, not yours. So the problem exists not only for mobile users, but for anyone who clicks a link shared by mobile users. Think of how often content is shared on social networks. This presents a real problem. Admittedly, Google is working on fixing this, but only for Google Chrome users. People using other browsers, including every iPhone user, will have the same problem.

AMP means Google’s stamp of approval replaces yours

As mentioned above, AMP-optimized content shows up in a carousel at the top of Google search results. Users will often view this content as Google’s and not that of the original content provider. The problem is that this same mental switch happens with all AMP-optimized content. This means your carefully researched article could appear right next to a sensationalized biased news story with nothing to differentiate their content from yours.

Others have pointed this out, but early adopters of AMP include a lot of the biased, sensationalized news sources and clickbait farms that rely on user clicks at any cost and often put out misleading or blatantly false content to achieve their goals. These sites are given the same stamp of approval that your content will receive, and will show up right alongside it.

This association has no quality control aside from simple adherence to Google’s technical standards for AMP—any content that’s optimized for AMP and fits the search criteria will show up in the carousel. With the tendency of users to read headlines and excerpts without checking the full article, this can be a real problem for real content providers in a sea of desperate clickbait.

AMP means more development work

Even though AMP is mostly a collection of existing technologies, it doesn’t mean it’s an easy switch. There are still some significant changes that have to be made to the code to get your content AMP-ready.

The big one is third-party content, coming from other sites which may not be AMP-optimized. This includes advertisements. Just because your code loads quickly doesn’t mean that other code from someone else will, and exceptions and work-around are usually made for things like this. Advertisements have to be coded in a different way and usually load slowly after your content. A big discrepancy between your content and your advertisements makes them more annoying for users, which decreases click-through rates.

Another problem is that third-party libraries—and most custom code—are banned outright. This means giving up some functionality that you may want, such as image carousels, scroll effects, and even show/hide capabilities on most navigation menus. This also means rewriting all of your CSS to be inline rather than pull from an external file, which can be a huge chunk of work for some pages. AMP is optimized for basic content, which means it makes creative flourishes and more advanced features much harder to implement. Admittedly, omitting these things can be a good idea, but there will be many cases when you need them and can’t have them because of AMP.

Because of these challenges, websites that support AMP maintain two versions of each page: one built with the features they want for everyone, and another built for AMP compliance. Yes, that means almost doubling the work to support AMP. Analytics tools are also incompatible with AMP, which means that checking any analytics data means compiling it from two sources: AMP’s limited analytics data and data from whatever you’re using for your regular site.

AMP isn’t that much faster

Google built AMP for speed on mobile devices, but the framework doesn’t necessarily provide a significant speed boost—especially since using AMP means loading an additional JavaScript library from Google. Smart optimization of mobile experiences, such as eliminating large frameworks and libraries and basic optimization techniques, can provide the same speed boost that AMP offers, but do it for all users—not just mobile Google users.

Case in point: Maciej Cegłowski, the founder of Pinboard, recreated Google AMP’s demo page without the Google AMP JavaScript library. The recreated page is faster than Google’s version. Web developer Ferdy Christant also published an alarming comparison of the same page with and without AMP showing that the AMP version of the page was almost four times slower than the non-AMP version.

AMP pages usually do load faster for mobile users coming from Google (but not always), but this isn’t because of some miraculous optimization power—it’s because Google pre-caches AMP-optimized pages while you’re on the search engine results page. For users visiting the AMP pages from other sources (like AMP pages shared on social media), the pages can actually load slower than similarly-optimized pages that don’t use AMP. AMP forces developers and site managers to optimize their sites, but it’s not the only way to optimize a site, nor is it the best.

AMP benefits Google, not content providers

AMP is framed as a way to benefit users and serve them the content they want faster, but the reality is that the primary benefactor here is Google. AMP encourages users to stay on Google’s page instead of visiting the content creators’ pages, increasing their ad revenue instead of yours. It means giving control of your content over to Google. And once you opt in, it’s very hard to opt out. Google knows it’s a hard sell, so they’re trying to bribe websites into using it by offering a page rank boost, but the end result is still damaging to both users and especially to site marketers. AMP may not always be a terrible thing, but there are many cases when it is, and those have to be seriously considered before making the decision to implement it.

Written by Staff