Intent to Ship: Resource timing: get encoded/decoded body size with CORS instead of TAO

[Chromestatus]

Contact emails

nrose...@chromium.org

Specification

https://w3c.github.io/resource-timing

Summary

For cross-origin resources, require that a resources is fetched with CORS for it to show its encoded/decoded body sizes as well as transferSize. For encodedBodySize/decodedBodySize this would replace the Timing-Allow-Origin gate, while transferSize would require both.

Blink component

Blink>PerformanceAPIs>ResourceTiming

Web Feature ID

resource-timing

Motivation

It was realized a while ago that when a resource opts-in to "Timing-Allow-Origin" it should only opt-in to information that is clearly related to *timing*. Body sizes, as well as the existing CORS-protected attributes like responseStatus, contentType and contentEncoding, tell more about the content of the resource than about the process of fetching it.

Initial public proposal

No information provided

TAG review

No information provided

TAG review status

Not applicable

Goals for experimentation

None

Risks

Interoperability and Compatibility

No information provided

Gecko: Shipped/Shipping

WebKit: Shipped/Shipping WebKit only exposes body sizes for same-origin resources, so they are more strict than this.

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?

No information provided

Debuggability

No information provided

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

No

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

No

Flag name on about://flags

No information provided

Finch feature name

ResourceTimingUseCORSForBodySizes

Rollout plan

Will ship enabled for all users

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40251936

Estimated milestones

Shipping on desktop	158
Shipping on Android	158
Shipping on WebView	158

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

No information provided

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5195340595724288?gate=6079863659298816

This intent message was generated by Chrome Platform Status.

[Vladimir Levin]

I assume this is available on all six Blink platforms? Could you check that box

 

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

No

Why not? I think there should be WPTs to ensure we can get to interop. Is that possible to add?

[Noam Rosenthal]

Done

>
>
> Is this feature fully tested by web-platform-tests?
> No
>
>
> Why not? I think there should be WPTs to ensure we can get to interop. Is that possible to add?
>

Oh sorry, of course there are WPTs.
See https://github.com/web-platform-tests/wpt/blob/123e9cf261ab3119dfbf9b6fac4cd9ca799dbf03/resource-timing/body-size-cross-origin.https.html
(added to the chromestatus).

[Vladimir Levin]

Hey,

Thanks! The relevant tests seem to be failing in Blink on wpt.fyi. Can you clarify if the idea is that you will fix them by implementing/shipping this change?

Thanks,

Vlad

[Noam Rosenthal]

On Wed, Oct 7, 2026 at 5:57 PM Vladimir Levin <vmp...@chromium.org> wrote:
>
> Hey,
>
> Thanks! The relevant tests seem to be failing in Blink on wpt.fyi. Can you clarify if the idea is that you will fix them by implementing/shipping this change?

Confirmed, this is currently implemented in blink behind "test" rather
than "experimental", so flipping the switch would make them green.

[Vladimir Levin]

Great,

LGTM1

Thanks,

Vlad

[Dan Clark]

LGTM2

[Alex Russell]

Do I understand correctly that this is going to reduce the scope of existing metrics information via TAO? Do we have reason not to think of this as a breaking change and/or some metrics that would cabin the risk somehow?

Best,

Alex

[Noam Rosenthal]

On Mon, Oct 12, 2026, 7:43 PM Alex Russell <sligh...@chromium.org> wrote:

Do I understand correctly that this is going to reduce the scope of existing metrics information via TAO?

Correct.

Do we have reason not to think of this as a breaking change and/or some metrics that would cabin the risk somehow?

It's a change that reduces the availability of some metrics in certain situations.

However, developers that care enough about these metrics can add crossorigin HTML attributes and cross-origin CSS modifiers (which were added, in part, to mitigate this), and get them back.

The security/performance trade offs were carefully examined when we specified and discussed this back in 2022. We just never shipped it...

See discussion in https://GitHub.com/resource-timing/issues/220, which was also discussed in WebPerfWG.

[Alex Russell]

I'm not convinced that it's so easy for developers to change this. Can we do some outreach to see who might be impacted?

[Yoav Weiss (@Shopify)]

This will have significant compat implications. We need to think carefully about this change.

On Wednesday, October 14, 2026 at 6:19:16 PM UTC+3 Alex Russell wrote:

I'm not convinced that it's so easy for developers to change this. Can we do some outreach to see who might be impacted?

I doubt outreach would help here.

The developers who care about this are not necessarily the developers writing the HTML and can add the crossorigin attributes. Beyond that, there's breakage risk in enabling this attribute for resources whose backend doesn't support CORS.

[Noam Rosenthal]

On Wed, Oct 14, 2026 at 4:27 PM Yoav Weiss (@Shopify)
<yoav...@chromium.org> wrote:
>
> This will have significant compat implications. We need to think carefully about this change.

We already had this conversation as part of WebPerfWG in 2022. We've
standardized this and Gecko/WebKit have already shipped this.
Thinking carefully is always good but what exactly do you suggest?

> On Wednesday, October 14, 2026 at 6:19:16 PM UTC+3 Alex Russell wrote:
>
> I'm not convinced that it's so easy for developers to change this. Can we do some outreach to see who might be impacted?
>
>
> I doubt outreach would help here.

Agreed. We'll get the same feedback we received at WebPerfWG:
a) We don't like losing information
b) We don't have an alternative for the cross-origin leak.

I think at this point we can either:
1. ship it as is and live with missing encoded/decoded body sizes in
some scenarios. It doesn't drop actual timing information.
2. drop it and live with the cross-origin leak and interop mismatch.
3. investigate other avenues - this is currently not planned and it's
unclear what that would entail.

[Noam Rosenthal]

Important correction: Safari has not shipped this but supported the spec change.
Safari currently still supports body sizes only for same-origin.
So currently each browser does something different for body sizes as
seen in https://wpt.fyi/results/resource-timing/body-size-cross-origin.https.html?label=master&label=experimental&aligned.

[Noam Rosenthal]

For impact measurement, I ran an extensive http archive query:
https://gist.github.com/noamr/47ad2708f4fca6b0f2b462f70ca0c52a

According to this query, 20% of cross-origin resources would gain body
sizes, and about 15% would lose body sizes.
When splitting by resource type, the variation is big though - e.g.
20% of cross-origin images would lose body sizes and 2% would gain
body sizes.
The number for images would go down to ~12% if accounting for image
responses that already return a global CORS response
(Access-Control-Allow-Origin: *) without a CORS request (Origin: ...).

I hope this data helps us make the right decision.

[Alex Russell]

Thanks so much for this analysis; it's super helpful.

Given that I'm not sure how to think about this, would you be willing to join the Weds API OWNERS call to discuss compat and strategies for mitigating risk?

Best,

Alex

[Noam Rosenthal]

Yes, I'll join that briefly to discuss this. Vlad has sent me an invite (thanks!).