Intent to Ship: Resource Timing: Add spec-compliant Service Worker Router timing fields

[Keita Suzuki]

Contact emails

suzuk...@chromium.org, sisid...@chromium.org, yyana...@chromium.org

Specification

https://github.com/w3c/resource-timing/pull/415

Summary

Adds the `workerMatchedRouterSource` and `workerFinalRouterSource` attributes to the Resource Timing and Navigation Timing APIs. These attributes allow developers to identify which Service Worker Static Router rule was matched and the final source used for the request. Note on Deprecation: This change focuses exclusively on adding the spec-compliant fields. We will be sending a separate Intent to Deprecate (I2D) for the existing non-compliant fields (`workerMatchedSourceType` and `workerFinalSourceType`) once we have gathered sufficient usage data from our UseCounters.

Blink component

Blink>ServiceWorker

Web Feature ID

resource-timing

Motivation

The original field names (`workerMatchedSourceType` and `workerFinalSourceType`) were introduced during the experimental phase and used throughout the Origin Trial (M131–M139) . However, the specification has since settled on the names `workerMatchedRouterSource` and `workerFinalRouterSource` to be more descriptive and consistent with the broader API. Renaming these fields is critical for ensuring that Chromium remains spec-compliant and provides a stable, interoperable interface for web developers.

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Issues addressed

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: No signal

WebKit: No signal

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. This change is purely additive (adding the new fields) and does not change the behavior of existing APIs in a way that would break WebView-based applications

Debuggability

No information provided

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

Flag name on about://flags

No information provided

Finch feature name

No information provided

Non-finch justification

No information provided

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Availability expectation

Feature is available on Web Platform Baseline within 12 months of launch in Chrome.

Adoption expectation

Feature is used by specific partner(s) to provide functionality within 12 months of launch in Chrome. Feedback from the Origin Trial indicated that developers already find the router source information highly valuable for tracking and attribution.

Adoption plan

We will notify developers of the new field names via technical blog posts and documentation updates. The temporary coexistence of old and new fields ensures a smooth transition for current users.

Non-OSS dependencies

Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function?

No.

Estimated milestones

Shipping on desktop	149
Shipping on Android	149
Shipping on WebView	149

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).

None. The corresponding spec changes are already added. These fields are being added specifically to match the finalized specification. Reference: https://github.com/w3c/resource-timing/pull/415

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5172259800088576?gate=5871730453250048

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

It looks like the API owners accepted the interop risk when approving this to ship before the PRs landed.

Can you point us to the spec discussion that led to the name change?

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFXMW90_sBa4FtsM3%2B%3D4LXx0EL9W%2BxdRW%2BzNgAp5cNLwv7mR2g%40mail.gmail.com.

[Rick Byers]

In particular the question is whether we're better off trying to change the spec to match what we've shipped, or change what we've shipped to match the spec. To resolve this I think we need to know:

• What signals do we have from other implementors in terms of which name they've shipped or prefer to ship?
• What is the compat risk (eg. UseCounter) of the APIs we've already shipped? If the usage is already high then it's unlikely we can unship it, so we should evaluate the compat risk before deciding to embark on a rename.

Thanks,

   Rick

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSL%2BKwEAV6ObwQRLn5ZcoH17choN_ka-6EWGw_L178zhCw%40mail.gmail.com.

[Yoshisato Yanagisawa]

Hi Yoav and Rick,

Thank you for raising this point. I believe there is a misunderstanding regarding the background that necessitates this Intent to Ship.

The initial Intent to Ship for this feature already included a link to the specification's Pull Request, which defined the attributes as `workerMatchedRouterSource` and `workerFinalRouterSource`. Unfortunately, our team, including the authors and reviewers, overlooked the naming mismatch between the specification and the Chromium code when the feature was shipped. This oversight led to the release of the non-compliant fields (`workerMatchedSourceType` and `workerFinalSourceType`).

The root cause of the inconsistency was not a subsequent spec discussion in WebPerfWG (as seen in the 2024 and 2025

 meeting minutes). Instead, the issue appears to have originated from an internal naming convention within Chromium's implementation. Specifically, internal usage of the `ServiceWorkerRouterSourceType` enum (a successor to the SourceType used in older code) seems to have led the implementation to incorrectly apply the Type suffix. This was the source of the code diverging from the specification's proposed notation, which was defined early in the process (in this GitHub Issue Comment).

Therefore, any search for a specification discussion that changed the name after the I2S approval will not be fruitful, as the spec name was intended to be compliant from the beginning.

I sincerely apologize for this internal naming inconsistency and the resulting need for this follow-up Intent to Ship to align Chromium with the finalized specification.

Regarding Rick's questions:

• What signals do we have from other implementors in terms of which name they've shipped or prefer to ship?
  
  

• The naming mismatch was discovered by a vendor from another browser.
• What is the compat risk (e.g., UseCounter) of the APIs we've already shipped?
  
  
  The current UseCounter metrics show approximately 5% usage. However, this count may be inflated because developers often list all attributes in a performance entry, so I doubt the actual number of users depending on the non-compliant fields is that high.
  • workerMatchedSourceType https://chromestatus.com/metrics/feature/timeline/popularity/5117
  • WorkerFinalSourceType https://chromestatus.com/metrics/feature/timeline/popularity/5118

Thanks,
Yoshisato

2026年4月16日(木) 0:17 Rick Byers <rby...@chromium.org>:

[Yoav Weiss (@Shopify)]

Can we align the spec to the implementation, rather than the other way around?

The current names seem fine at first glance..

[Mike Taylor]

On 4/16/26 2:31 a.m., Yoav Weiss (@Shopify) wrote:

Can we align the spec to the implementation, rather than the other way around?

The current names seem fine at first glance..

On Fri, Apr 17, 2026 at 2:24 AM Yoshisato Yanagisawa <yyana...@chromium.org> wrote:

Hi Yoav and Rick,

Thank you for raising this point. I believe there is a misunderstanding regarding the background that necessitates this Intent to Ship.

The initial Intent to Ship for this feature already included a link to the specification's Pull Request, which defined the attributes as `workerMatchedRouterSource` and `workerFinalRouterSource`. Unfortunately, our team, including the authors and reviewers, overlooked the naming mismatch between the specification and the Chromium code when the feature was shipped. This oversight led to the release of the non-compliant fields (`workerMatchedSourceType` and `workerFinalSourceType`).

The root cause of the inconsistency was not a subsequent spec discussion in WebPerfWG (as seen in the 2024 and 2025

 meeting minutes). Instead, the issue appears to have originated from an internal naming convention within Chromium's implementation. Specifically, internal usage of the `ServiceWorkerRouterSourceType` enum (a successor to the SourceType used in older code) seems to have led the implementation to incorrectly apply the Type suffix. This was the source of the code diverging from the specification's proposed notation, which was defined early in the process (in this GitHub Issue Comment).

Therefore, any search for a specification discussion that changed the name after the I2S approval will not be fruitful, as the spec name was intended to be compliant from the beginning.

I sincerely apologize for this internal naming inconsistency and the resulting need for this follow-up Intent to Ship to align Chromium with the finalized specification.

Regarding Rick's questions:

• What signals do we have from other implementors in terms of which name they've shipped or prefer to ship?
  
  
  The naming mismatch was discovered by a vendor from another browser.

This is helpful to know, but doesn't quite get at the core concern of the question. Has another browser/implementer shipped this API with the specced name? Or is someone about to ship the API, and that's how they noticed?

Having WebKit and Mozilla vendor positions would have helped answer this 

If answer to either question is "no", I think the best path forward is what Yoav suggests: we should make the spec match the shipping implementation. It's an unfortunate mistake, but it took about a year for anybody to notice it, and the usage numbers suggest developers are able to use it as-is (to Yoav's point that the current names seem fine).

• What is the compat risk (e.g., UseCounter) of the APIs we've already shipped?
  
  
  The current UseCounter metrics show approximately 5% usage. However, this count may be inflated because developers often list all attributes in a performance entry, so I doubt the actual number of users depending on the non-compliant fields is that high.
  • workerMatchedSourceType https://chromestatus.com/metrics/feature/timeline/popularity/5117
  • WorkerFinalSourceType https://chromestatus.com/metrics/feature/timeline/popularity/5118

5% is very, very high. I assume we don't have a way to know if sites are depending on these fields, right (presumably the info is used by backend systems, so we can't know what would break or not)?

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKDTNmGeGWFi2r1T5i50HU7TqmDqU28L4JzWdLF%2BZpXPg%40mail.gmail.com.