Interesting suggestion. Do we know how often users load pages that have AMP variants? I'd imagine that's rare, at least for loads where previews is triggered. Collecting that data could be a good first step. 

 

I see that Bryan and Charles added some UMA to track the number of pages loaded from an AMP cache, but the numnber of hits is very low:

https://uma.googleplex.com/p/chrome/histograms/?endDate=20170215&dayCount=1&histograms=PageLoad.Clients.AMPCache.ParseTiming.NavigationToParseStart&fixupData=true&otherVersions=true&showMax=true&filters=channel%2Ceq%2C1%2Cisofficial%2Ceq%2CTrue&implicitFilters=isofficial

Bryan/Charles -- do you know what's up with this UMA?

I don't think we necessarily need to block on getting more data before implementing something like this, if we can show that there's a performance win. Doing this server-side first might be the right approach since that would require zero (?) Chrome changes.

Related: crbug.com/672466 which is about preferring AMP URLs in Zine suggestions.

ryansturm@ added these histograms (thanks ryan!).

Happy to support making them better, but there's some somewhat challenging work here.

AMP page loads are somewhat unique and not always supported by the page load metrics infra.

The main issues are that many navigations to AMP documents:
1. load the main AMP document in an iframe (AMP viewer, for example)
2. navigate to the AMP document using an in-page navigation managed at the JS layer

RE: 1, pages that load their main content in an iframe have historically been uncommon, and supporting that use case in page load metrics added complexity, so we never got around to it.

RE: 2, there's no canonical browser-level API to track in-page navigations managed by JS. In general, these types of navigations are free to do whatever they want, and there's no clear concept of when a navigation started, whether there's a main html resource being loaded, or what constitutes a 'first paint' etc.

We have some bugs open related to these issues which people are welcome to tackle. I'd want to meet to discuss potential implementation details and make sure we're approaching the problem in a way that generalizes beyond AMP, if at all possible.

https://bugs.chromium.org/p/chromium/issues/detail?id=661702
https://bugs.chromium.org/p/chromium/issues/detail?id=661701

RE: comment #2, a server-side experiment that redirects to the AMP variant should be simple enough to implement. To measure the benefit we'd need to separate performance timings for such redirects from control -- I'm not sure we can re-use the existing metrics, but we should explore. 

Assigning to Raj since he is currently working on a client side experiment for AMP redirects.