Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Report that Critical-CH was used to restart a navigation #177

Closed
yoavweiss opened this issue Apr 20, 2022 · 5 comments · Fixed by #188
Closed

Report that Critical-CH was used to restart a navigation #177

yoavweiss opened this issue Apr 20, 2022 · 5 comments · Fixed by #188
Projects

Comments

@yoavweiss
Copy link
Contributor

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.

@yoavweiss yoavweiss added this to New in Triage Apr 21, 2022
@yoavweiss yoavweiss moved this from New to Discuss in Triage Apr 21, 2022
@nicjansma
Copy link

nicjansma commented May 11, 2022

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.

@nicjansma
Copy link

nicjansma commented Mar 17, 2023

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 🤔

@yoavweiss
Copy link
Contributor Author

^^ @arichiv @miketaylr

@miketaylr
Copy link
Member

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

@arichiv
Copy link
Member

arichiv commented Mar 17, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Triage
Discuss
Development

Successfully merging a pull request may close this issue.

5 participants