I don't really understand this? I've never used AMP directly but I use Ghost which comes packaged with AMP. How does AMP change the domain of your content?
Google Search, when used from a mobile user-agent, such as a mobile browser or some mobile-resident Google Search integration like the Google Now Launcher Search Bar, will show some results' AMP-equivalents, and uses AMP-availability as a ranking signal.
When such an AMP search result is opened from the aforementioned Google Search source, it will open in a Google Search-wrapped frame reader, such that the outside is Google Search -- although this is not visually obvious to the user -- while the inside the AMP article. The browser-level URL for this endpoint begins with 'google.com/amp/'. While it's now possible to get the article's original link from this viewer, this was not present at launch, and it was a frequent source of criticism.
This is a brief restatement of a more in-depth description I gave in a different thread [1].
Google uses AMP for caching. When you click on the link, they are serving cached content from their own servers. They say it promotes user experience because it is faster. The average user can hardly tell the difference, and they might never go to your server.
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-exis... for some ideas on how to improve the platform so the caches wouldn't be necessary for much of AMP.
But it is an attack on the open web, Google is now sealing off the 'user leak' holes like Facebook did to keep people within their ecosystem. That's all well and good for Google, but we all rely on a relatively neutral search engine and we've relied on Google not to come back down the abstraction levels and into the application space. From a business point of view the game has changed and Google need to be treated as hostile even if they don't know it yet
If speed is the answer, then sure offer AMP, but also offer a lightning bolt next to pages that load within 'x' milliseconds. Reward speed regardless of implementation
AMP isn't really about speed -- it's about the appification of the open WWW.
The correct way to fix these problems would be to teach people how to make their sites faster rather than enforce restrictions on how they create and monetize their online publications.
"Pinboard founder Maciej Cegłowski already recreated the Google AMP demo page without the Google AMP JavaScript and, unsurprisingly, it's faster than Google's version."
> Maciej Cegłowski already recreated the Google AMP demo page
He solved a different problem.
I don't think anybody at AMP claims that fast pages aren't possible. Their claim is that there's a need to enforce certain rules to achieve a certain quality of service.
> teach people how to make their sites faster
In a way, that's what AMP is doing. It picks a subset of HTML5 that can be rendered efficiently, and - for now - uses javascript to fill in the blanks (eg. where desired capabilities are forbidden due to how they're commonly implemented: provide build a polyfill that's better suited) and for enforcement of these rules.
As linked in my parent post, there are already efforts to offload some of these constraints into standards to be enforced by browsers - I fully expect the AAMP scaffolding to let go of that soon after (or revert to shims)
Your content gets served on Google.com domain with a giant "back" button at the top that takes users back to Google rather than deeper into your site. It also creates restrictions on what you can publish and how you can monetize.
