Intent to Ship: Resource timing: revert responseStart change and introduce firstResponseHeadersStart

[Chromestatus]

Contact emails

nrose...@chromium.org

Explainer

None

Specification

https://w3c.github.io/resource-timing/#dom-performanceresourcetiming-finalresponseheadersstart

Summary

Resource timing: - responseStart returns the first response, either early hints (interim) or final - Expose the final response headers (2xx/4xx/5xx) time as finalResponseHeadersStart.

Blink component

Blink>PerformanceAPIs>ResourceTiming

TAG review

None

TAG review status

Not applicable

Risks

Interoperability and Compatibility

This fixes responseStart to work like before and like firefox/safari, which makes it an interop *fix*. Compat-wise, this would change current dashboards that rely on the current chromium behavior of responseStart, and we would need to reach out to RUM providers who rely on these dashboards to update.

Gecko: Positive (https://github.com/mozilla/standards-positions/issues/1108) Mozilla participated in the WebPerfWG meeting where we resolved on this.

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/424)

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

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

Yes

https://wpt.fyi/results/resource-timing/interim-response-times.html?label=experimental&label=master&aligned https://wpt.fyi/results/resource-timing/interim-response-times.h2.html?label=experimental&label=master&aligned

Flag name on about://flags

ResourceTimingFinalResponseHeadersStart

Finch feature name

ResourceTimingFinalResponseHeadersStart

Requires code in //chrome?

False

Tracking bug

https://b.corp.google.com/issues/40251053

Availability expectation

The change to responseStart is already available in the web platform mainline, and this aligns with it.

Adoption expectation

RUM providers rely on current behavior, so they would have to align very quickly by adopting the new values.

Adoption plan

DevRel outreach and using the existing RUM provider partner channels.

Estimated milestones

Shipping on desktop	133
DevTrial on desktop	132
Shipping on Android	133
DevTrial on Android	132
Shipping on WebView	133

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

This is a resolution of https://github.com/w3c/resource-timing/issues/345

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5158830722514944?gate=5072033166393344

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

LGTM1. Please keep us updated on how the outreach to RUM providers is going, since it sounds like that is the only compat concern.

[Noam Rosenthal]

On Mon, Nov 18, 2024 at 7:55 AM Domenic Denicola <dom...@chromium.org> wrote:

LGTM1. Please keep us updated on how the outreach to RUM providers is going, since it sounds like that is the only compat concern.

Will do! They've been informed throughout the discussion and take an active role in the WebPerfWG, so this is a well managed process.

 

[Mike Taylor]

LGTM2 - out of curiosity, how large is the set of RUM providers?

[Noam Rosenthal]

LGTM2 - out of curiosity, how large is the set of RUM providers?

I'd say about a dozen can fit the title comfortably?

Note that it's not the only people using the performance timeline APIs - big companies, CDNs and performance consultants use it directly.

But they are the ones that are most affected by behavior changes that have to do with early hints, which are somewhat new anyway.

[Yoav Weiss (@Shopify)]

LGTM3

It should be noted that the risk here regards the intersection of sites that collect RUM and use Early Hints.

Shopify is one of them, and (with my Shopify hat on) it is ready for this change.

CloudFlare, Akamai and Fastly would be other entities we'd want to make sure are ready for this change. Adding Tim Kadlec, Nic Jansma and Patrick Hammann to confirm on their respective sides.

[Nic Jansma]

We understand and agree with the proposal here, and will be ready for the changes.

[Noam Rosenthal]

On Tuesday, November 19, 2024 at 10:13:57 AM UTC Yoav Weiss wrote:

LGTM3

It should be noted that the risk here regards the intersection of sites that collect RUM and use Early Hints.

Shopify is one of them, and (with my Shopify hat on) it is ready for this change.

CloudFlare, Akamai and Fastly would be other entities we'd want to make sure are ready for this change. Adding Tim Kadlec, Nic Jansma and Patrick Hammann to confirm on their respective sides.

It's been 7 days and we haven't heard back from Tim or Patrick.

Since this has been discussed in detail both at the WebPerfWG and at TPAC, may we proceed with shipping?

[Yoav Weiss (@Shopify)]

Yeah, this was not a blocker.

[Tim Kadlec]

We (Cloudflare) understand the change are will be good to go here.