AMP Project Blog

Be sure to read Paul Bakaus's response, "Why AMP caches exist", to hear both sides of the issue. https://amphtml.wordpress.com/2017/01/13/why-amp-caches-exist/amp/

(Though, actually, it's only a response in spirit; Bakaus's article was posted about a week earlier than Miessler's.)

I think the problem with the AMP cache model is that, because you need to link directly to the cached URL, you commit to exactly one cache provider. If Bing were to also implement their own validated AMP cache for Bing search results, you can't have one link point to both; you're either AMPed in Google results or in Bing results, and, by being marginally bigger, Google wins all of the pie. That's no good.

How might we change the AMP standard, or the trust model around AMP caches, to get the same performance wins while still enabling competition?

AMP specifications allow for other cache servers, of which CloudFlare[0] has recently implemented one. You could implement your own if you like.

AMP also specifies that the canonical page URL should be used when sharing, though the cached URL is currently what's shown in the browser. Their last developer update[1] said they're working to address this, however for all relevant purposes Google's own systems already currently consider AMP traffic and results to be attributed to the original source.

[0] http://www.businessinsider.com/cloudflare-adopts-google-amp-2017-1

[1] https://amphtml.wordpress.com/2017/01/13/why-amp-caches-exist/

> Google amends its cached AMP search results with Schema.org and OpenGraph metadata, so posting the link to any platform that honors these should result in the canonical URL being shared.

downvoters: this is 100% true. AMP has some nice standards on how to make a fast page but at the end of the day, google's re-hosting your page in a place where it can fetch in advance while obeying the same-origin policy, and clicking a result is the moral equivalent of unsetting a "display: hidden" attribute on the page.

AMP only works today because it's re-hosted inside the origin (google.com), so much that in order to fix this in the future, they'll have to rush out a new web standard and implement it in chrome (and hope other browsers do the same:) https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/

FWIW they announced their intention to do this over two years ago now, in March 2018:

> Based on what we learned from AMP, we now feel ready to take the next step and work to support more instant-loading content not based on AMP technology in areas of Google Search designed for this, like the Top Stories carousel. This content will need to follow a set of future web standards and meet a set of objective performance and user experience criteria to be eligible.

Source: https://amphtml.wordpress.com/2018/03/08/standardizing-lessons-learned-from-amp/

It really depends on what you want to do: disseminate information (with a canonical URL that you control) or shovel users to your server?

In the former case, AMP caches are a reasonable compromise since it's really just a free CDN.
In the latter case, that cache is annoying because of how it needs to fit in the design of the contemporary web. See the last paragraph of https://amphtml.wordpress.com/2017/01/13/why-amp-caches-exist/ for some ideas on how to improve the platform so the caches wouldn't be necessary for much of AMP.

It's funny how no one was up in arms when facebook (the leading source of publisher traffic) did their version of accelerated pages.

AMP serves a purpose for the end user and it does so well, it loads instantly and doesn't consume much data in the process.

As for their "demands":

1. Google already states that AMP pages are ranked higher because they're faster to load.

2. I'm not sure if it's related but they they addressed that only yesterday: https://amphtml.wordpress.com/2018/01/09/improving-urls-for-amp-pages/