The mobile web can be frustrating. Smartphones and tablets are becoming faster every year, but modern sites usually outpace them by becoming more complicated. While there are efforts to improve site load times, smartphones have to deal with other obstacles as well. Cellular network connections can become congested, especially in densely-populated areas, and budget phones often aren't speedy enough for a good browsing experience.

There have been many different products and technologies designed to speed up mobile browsing. Some browsers, like Opera Mini and Amazon Silk, render most of the page on a server and send the result to the user's device. Alternatively, most modern browsers support Service Workers, which allow sites to cache resources locally for faster loading on subsequent pages.

Responsive web design has been the norm for a few years now, meaning most sites no longer have specific pages for mobile devices. However, the idea of lightweight pages for mobile users hasn't gone anywhere. Facebook unveiled 'Instant Articles' in 2015, which are optimized HTML pages with limited functionality. These pages load much quicker on mobile devices, but they only worked when opened from the Facebook app.

Google responded later that year with Accelerated Mobile Pages, or 'AMP' for short. Like Facebook Instant Articles, AMP uses a limited subset of web features to create pages that load extremely fast. They also aren't limited to social media - AMP pages show up in Google Search results, the Google Feed, Google News, and some third-party applications.

Roughly two and a half years after AMP was introduced, it still has major usability and technical shortcomings that aren't being addressed. Even though Google has made improvements since then, the product's core issues remain.

How AMP works

Before diving into why AMP has problems, I want to explain how the technology works and what limitations it has. Google describes it as "an open-source library that provides a straightforward way to create web pages that are compelling, smooth, and load near instantaneously for users."


Left: Normal article; Right: AMP article loaded from Google Search

On sites that support AMP, every page will have an AMP version (usually generated automatically using a template). If you tap on an article from Google Search that has an AMP equivalent, Google will display the AMP page instead.


The key difference between AMP documents and normal pages is that AMP uses special HTML elements called 'components.' For example, developers can't embed images using the normal <img> tag, they have to use the 'amp-img' component. If they want to embed a YouTube video, they have to use the 'amp-youtube' instead of the general embed code, and so on.

These components are built with performance and load times as top priorities. Let's say you visit an article with a dozen images throughout the content. That's 12 different images your browser has to load, and if you decide to close the window halfway through the article, your phone spent all that time downloading and rendering images for nothing. On AMP articles, images are (usually) only loaded when you actually scroll to them, which speeds up the initial load time.

Embedded media content is another way browsers can slow to a crawl. AMP has specific methods for adding video/audio players, YouTube videos, Imgur galleries, and other popular embedded content. Interactivity is limited, but they usually load quicker than normal JavaScript/iframe embeds. AMP also has components for social media buttons, advertisements, app banners, and other common web elements.

The functionality for all these components comes from the AMP runtime, a JavaScript file embedded in every document. Google says the runtime "provides implementations for AMP custom elements, manages resource loading and prioritization and optionally includes a runtime validator for AMP HTML for use during development."


Custom elements are only half of what makes AMP so fast. Google already crawls the web to help compile search results, and if an AMP version of a page is detected, Google will save a copy of that page on its own servers.


For example, when you tap on an AMP article from TechCrunch on Google Search, Google's copy of the page will be shown instead of the AMP document on TechCrunch's website. You can see this in the second screenshot above - the address bar has '' instead of ''

In most cases, this speeds up load times even further, since Google's servers are incredibly fast. But this also presents other problems that Google has been trying to address for years.

Obscuring the source

Google AMP has been criticized from the beginning for a number of reasons, but the user experience remains the worst part of AMP in my opinion. As you probably already know, Google prominently displays AMP articles in web search results. This is how most people find themselves on AMP pages.

When opening an AMP link, you technically never leave Google's site. The article is embedded in the search page, with a custom header at the top displaying what site the page is from. At first, it was difficult to obtain the original web address, but Google added a button for that last year. While this does add an extra step for people trying to find the original link, at least it's obvious.

Tapping the link button on Google Search shows the original URL.

Unfortunately, other sites and applications don't handle AMP nearly as well. Some apps now display the AMP versions of pages if they are available, including Google Feed, the Google+ Android app, Twitter, and others. The problem is that all of these use Chrome Custom Tabs to display links, so there is no button to see the original URL like there is on Google Search. The only exception I've found is in the new Google News app, which has a 'View original article' item in the overflow menu.

Take Google Feed, for instance. If you tap on an AMP article, it opens in a Chrome Custom Tab with the name of the site visible at the top. The only way to find the original link is to tap 'Share link...' in the overflow menu (some apps add a share button to the top bar). Not a great user experience at all.


Opening an article from Google Feed will display the AMP version, with no obvious way to find the original link.

This could be solved by adding the original link to every AMP article, preferably somewhere near the top. Unfortunately, most publishers either don't bother doing this, or they make the original link difficult to find. Ars Technica adds a "View non-AMP version" link just below the headline, and Ars is the only publication I've seen that does that.

More publishers need to do this.

There are a few different ways this could be addressed. Google could update the AMP runtime to mark pages as invalid if they don't include a link to the original article, perhaps giving publishers a month or two to update their templates before the change goes into effect.

The runtime could also inject the Google Search header (with the link button) directly into the page, so it would appear on all apps loading AMP pages. This could potentially break some pages, especially ones using certain CSS positioning methods, so the first option seems best.

At Google I/O 2018, Google said it wants to use Web Packing to show the original article link in the address bar. Simply put, Web Packing is a proposed web standard that allows sites to give other sites permission to use their address. Unfortunately, this is a browser-side fix, and other browser vendors are skeptical of implementing it.

Google needs to address this problem in a browser-independent way, especially as more and more apps switch to displaying AMP pages. The company already has an API to find AMP versions of pages, so Google definitely intends for other apps to display these links.

Technical problems

AMP also has a number of technical issues that harm the overall user experience. First, AMP pages still do not redirect to the original link on desktop browsers. This seems like an incredibly simple thing to fix - Google can just add a basic user agent check to the runtime. I'm not aware of any desktop sites or apps linking to AMP pages, but they are frequently posted to sites like Twitter and Reddit, which are obviously used by desktop and mobile users alike.

Another common criticism about AMP is the lack of any opt-out mechanism. There is no setting anywhere that will stop AMP links from appearing on web search or across Google's applications. I'm not sure if a global setting for AMP is feasible, especially one that would also apply to third-party applications linking to AMP pages, but I don't see why a toggle for web search (and maybe Google Feed/Google+) wouldn't be possible.

Finally, despite AMP itself working across all modern web browsers, the behavior on Google Search is wildly inconsistent. If you tap on an AMP link in web search on Chrome, the page is embedded within the search tab (and loaded from Google's cache). The article loads quickly, and users can easily find the original URL because Google adds the link button.


AMP page from Google Search on Chrome (left) and Opera (right).

If you tap on an AMP link in Opera, Samsung Internet, or Microsoft Edge, the article is loaded from the publisher's own website. This is problematic for two reasons. First, the page will load slightly slower, because it's being served from the publisher's site and not from Google's servers. Secondly, you can't easily find the non-AMP URL, because there is no embedded link button like there is on Google Search.

AMP works on all major browsers, but AMP links from Google search don't.

Opera, Samsung Internet, and Microsoft Edge all use slightly-tweaked variants of Chrome's 'Blink' engine, so they're perfectly capable of rendering Google search results and AMP pages in the same manner as Chrome. So why is Google making AMP less user-friendly on these browsers? To make matters worse, AMP links don't show up at all in Google Search for Firefox, even though Firefox is fully supported by AMP.

This is far from the first time that Google has limited web apps or features to Chrome, and it probably won't be the last. I can understand the company using Chrome to test functionality before rolling it out to other browsers, but AMP links have been in Google Search for nearly two years now.


Google isn't slowing down with AMP. The company is working on a new form of AMP articles that look like Snapchat stories, and it even wants to bring the technology to Gmail. At I/O 2018, Google said it was building AMP "for the post-destinations era." The company wants AMP to be everywhere content is embedded - algorithmic feeds, social media, email, and beyond.

AMP is already successful, mostly because Google prioritizes search results from sites with AMP over those without it. But as I've explained in this post, the technology still has usability issues that aren't being worked on.

There are other potential problems with AMP that others have addressed, like how it helps spread fake news and encourages users to not leave Google's site. AMP for Gmail has attracted even more criticism, because it fundamentally changes how email works by allowing dynamic content. Do you want emails with changing content? No, me neither.

AMP has the potential to make mobile browsing significantly better, but if Google continues to prioritize publishers over users, AMP will only make the mobile web worse.

Alternate title: Google needs to AMP it up to 11 — and right now, it's at 4