[blink-dev] Intent to Prototype & Ship: Report Critical-CH caused restart in NavigationTiming

[Ari Chivukula]

Contact emails

ari...@chromium.org, mike...@chromium.org, yoav...@chromium.org

Specification

https://github.com/w3c/navigation-timing/pull/188

Summary

Websites can indicate that a particular Client Hint is critical to the page by including it in a `Critical-CH` HTTP response header. Doing so will trigger a connection restart if the hint listed in the `Critical-CH` HTTP response header could be (but wasn’t) included in the HTTP request initially sent. This intent proposes adding `readonly attribute DOMHighResTimeStamp criticalCHRestart;` to the `PerformanceNavigationTiming` interface.

Blink component

Blink>PerformanceAPIs>NavigationTiming

Motivation

It’s possible for websites to observe a change in the Navigation Timing related to `responseStart` and `requestStart`, but there is no explicit timestamp that indicates when this occurred. Without that it’s harder for sites to detect the impact that the `Critical-CH` HTTP response header has on connections. Developers (including Akamai) are interested in using this to better understand the impact of User Agent Client Hints / User Agent Reduction.

`criticalCHRestart` can only be set for top-level frames, as subresources and iframes ignore `Critical-CH` HTTP response headers.

TAG review

N/A, this is a small, incremental addition to an existing feature for convenience and the loaded website has other (less convenient) ways to detect a Critical-CH restart.

Compatibility & Interoperability

We would be the first to implement if approved.

Gecko: https://github.com/mozilla/standards-positions/issues/767

WebKit: https://github.com/WebKit/standards-positions/issues/156

Web Developers: Requested by Akamai

Is this feature fully tested by web-platform-tests?

No, but it will be.

Tracking bug

https://crbug.com/1425910

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5140317616996352

[Alex Russell]

Please file an issue with the TAG as an FYI and let us know when they respond. Their job is to help us drive coherence across the platform and spot architectural patterns. There might be other occurances of similar oversights that they can help us spot and fix.

Best,

Alex

[Ari Chivukula]

https://github.com/w3ctag/design-reviews/issues/833

[Rick Byers]

This makes a lot of sense to me. Normally we prefer to approve shipping only after spec PRs have landed, it looks like the PR is blocked on some work from you including landing the WPTs, right? I'd suggest you get this all landed under a status=experimental RuntimeEnabledFeature and see if we can get the PR reviewed and landed in short order before trying to flip to status=stable, WDYT?

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0dacf540-c8be-4096-9ad1-bc7a99af630cn%40chromium.org.

[Ari Chivukula]

That differs from my past experience (in which a proposed spec change is sufficient to move forward with a launch), but if you want me to build and test it all behind a flag before I get the go ahead here that's fine.

~ Ari Chivukula (Their/There/They're)

[Rick Byers]

Hi Ari,

The documented process is to land features and specs before requesting approval to ship, as that gives the best possible chance for wide review and eventual interop. But we unfortunately often find ourselves in the position that this is impractical - eg. spec work blocked from landing due to lack of interest from a 2nd implementor (WHATWG venue) or just very slow reviews. So, if necessary, we are willing to approve based on a PR only but it's usually considered an exceptional situation. None of those seem to be the case here, it's just blocked on some impl and spec work right? In particular, we definitely want to see WPTs landed prior to shipping, so we're aligned with Noam on that request. chrishtr, foolip, yoav and I just discussed this now in the API owners meeting and are aligned on this being standard practice (though wouldn't be surprised if we've slipped up occasionally).

Thanks,

   Rick

[Ari Chivukula]

Works for me, didn't realize that was the standard order.

~ Ari Chivukula (Their/There/They're)

[Rick Byers]

Great, thanks Ari! No worries at all, checking to make sure the i's have been dotted and t's have been crossed is what the API owners are here for :-)

[Ari Chivukula]

I'm back! The code has been merged behind a flag w/ wpts: https://chromium-review.googlesource.com/c/chromium/src/+/4538244

The spec changes have been merged too:

https://github.com/w3c/navigation-timing/pull/188

https://github.com/WICG/client-hints-infrastructure/pull/153

~ Ari Chivukula (Their/There/They're)

[Chris Harrelson]

Thanks! LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DKthEYQEYGqoFyVWsp0xnm24QLEJfEoeZz9ZKB39PKtkg%40mail.gmail.com.

[Philip Jägenstedt]

LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw8xuuVTFCSKCyvqu-_7mnR6xpdzqbKkVd8T48S30rhJsQ%40mail.gmail.com.

[slightlyoff via Chromestatus]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfz2QM8hj_1GdYL%2BwGhey9HPjAAPcMwmJLUEkm697n2Sw%40mail.gmail.com.