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].
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.
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
It's only going to get worse with voice interfaces, see what Echo now does (https://www.youtube.com/watch?v=BXEu8RcneZQ).
A vibrant ecosystem is key to competition, it's not in our long term interests to let the web consolidate into an oligarchy
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."
https://www.theregister.co.uk/2017/05/19/open_source_insider...
Here are some recent articles about it:
https://www.theregister.co.uk/2017/05/19/open_source_insider...
