Wednesday, January 18, 2017

The Problem With AMP

The largest complaint by far is that the URLs for AMP links differ from the canonical URLs for the same content, making sharing difficult. The current URLs are a mess. They all begin with some form of https://wwww.google.com/amp/ before showing a URL to the AMP version of the site. There is currently no way to find the canonical link to the page without guessing what the original URL is.

[…]

AMP is about lock-in for Google. AMP is meant to keep publishers tied to Google. Clicking on an AMP link feels like you never even leave the search page, and links to AMP content are displayed prominently in Google’s news carousel. This is their response to similar formats from both Facebook and Apple, both of which are designed to keep users within their respective ecosystems. However, Google’s implementation of AMP is more broad and far reaching than the Apple and Facebook equivalents. Google’s implementation of AMP is on the open web and isn’t limited to just an app like Facebook or Apple.

[…]

The AMP HTML Specification states that all AMP HTML pages must load a JavaScript file from https://cdn.ampproject.org/. If you already run Google Analytics on your pages you probably don’t care that you’re loading yet another black-box JS file from Google. But sites that load absolutely nothing from external sources (such as this one) should understand the privacy and security implications that come along with running JavaScript that you don’t control.

greenspot:

Google is abusing its powers. The search rank is our currency and Google has pushed AMP sites to the top for some while. So, everybody is now building weird AMP layers for their sites. We went from a free to a proprietary mobile web in just a few weeks. And we can’t do anything. It feels like the times when the Internet Explorer tried to rule except that more people were complaining.

The open solution to a faster mobile web would have been so easy: Just penalize large and slow web pages without defining a dedicated mobile specification. That’s it.

John Gruber:

The lock-in aspect makes no sense to me. Why would I want to cede control over my pages to Google? AMP pages do load fast, but if publishers want their web pages to load fast, they can just engineer them to load fast. Best answers I got were that it wasn’t really strategic — publishers are going with AMP just because their SEO people are telling them to, because Google features AMP pages in search results. I suppose that is a strategy, but ceding control over your content to Google isn’t a good one in the long term.

Previously: Google’s Accelerated Mobile Pages.

Update (2017-02-09): Danny Sullivan:

As promised, Google is making a change to how it displays Accelerated Mobile Pages, so that users can easily view and share links that lead directly to publishers’ sites rather than to Google’s copy of the content.

John Gruber:

A little easier, but I would argue that they shouldn’t be doing this in the first place, and the new UI they’ve exposed is deliberately obfuscated.

[…]

This is what you call a begrudging UI. Google wants you to pass around the google.com-hosted AMP URL, not the publisher’s original URL. If they wanted to make it easier to share the original URL, the anchor button would be a direct link to the original URL. No need for a JavaScript popover. You could then just press the anchor button to go to the original, and press and hold for Safari’s contextual menu. And they could just use the word “Link” or “URL” instead of a cryptic icon.

Michael Rockwell:

A quick thought: wasn’t the whole point of AMP to shrink page sizes and increase the speed of browsing? If that’s the case, why does Google have to pre-cache these pages at all? Shouldn’t they be fast enough on their own without the help of Google’s servers?

Accelerated Mobile Pages (AMP) Google Privacy Security Web