navigation-timing
navigation-timing copied to clipboard
w3c
Report that Critical-CH was used to restart a navigation
Chromium recently got a report that it's hard for folks deploying Critical-CH as a backup mechanism to ACCEPT_CH frames to know if/when that backup was actually used, and triggered a restart of the navigation (which is likely to result in user-visible delay)
It may make sense for us to report that as part of navigation timing. This somehow connects to other "types" of navigations that we're considering reporting, so it may make sense to find an API shape that doesn't require a separate attribute per type.
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 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 https://github.com/w3c/navigation-timing/issues/37 and https://github.com/w3c/resource-timing/issues/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 🤔
