Report that Critical-CH was used to restart a navigation about navigation-timing HOT 5 CLOSED

Makes sense to me, I can propose this and try to get it in M114.

from navigation-timing.

Discussed on Apr 28 WebPerf WG call: https://w3c.github.io/web-performance/meetings/2022/2022-04-28/index.html

Summary:

• It seems fine to expose prefetch and Critical-CH signals orthogonally.

from navigation-timing.

From my testing, it looks like a Critical-CH-restarted navigation (in Chrome today) extends the requestStart to responseStart timestamps.

In other words, if the server takes +1 second to respond to the second request for the navigated resource (having restarted because a Critical-CH requested a hint that wasn't sent on the first request), responseStart will be at least 1 second after requestStart.

As we approach wider deployments of Client Hints for Chrome and the User-Agent Reduction timeline, I'd like to see if we can get this information into NavigationTiming. RUM providers could capture this information to help inform their customers about how effective UACH/UAR deployments and changes are, and to highlight any potentially costly restarted-navigations from Critical-CH.

A boolean flag for a Critical-CH-restarted request seems the easiest to implement. Ultimately if we get closer to #37 and w3c/resource-timing#21 it would be nice to have a breakdown of both requests in the NT data, but I'd take a boolean for now.

I'm not sure if there are any other impacts from UACH/UAR that we'd want to measure/report on, so pondering that 🤔

from navigation-timing.

^^ @arichiv @miketaylr

from navigation-timing.

I can see how this could be useful. WDYT, @arichiv?

from navigation-timing.