design-reviews#1113: Expose resource dependency in Resource Timing

#1113: Expose resource dependency in Resource Timing

Opened Jun 13, 2025

こんにちは TAG-さん!

I'm requesting an early TAG design review of Expose resource dependency in Resource Timing.

We plan to expose the dependency of the resources from RUM (real user monitoring) data. For a resource that's loaded from network, the "initiator info" points out what preceding resource triggered the acquisition of such resource.

As nicjansma@ points out here, the data exposed by this proposal is a RUM version of RequestMap tool. The RequestMap tool can be a good demonstration of the data to be exposed.

Explainer¹:https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ResourceTimingInitiatorInfo/explainer.md
User research: Optimizing content delivery speed greatly improves user experience by reducing delays and frustration from slow-loading websites. Websites and CDNs utilize resource dependency data to determine the sequence of resource loading, allowing them to minimize delays caused by dependencies and anticipate resource requests. This proactive approach accelerates content delivery. Additionally, resource dependency information aids in tracing rogue resources, mitigating online threats and strengthening security.
Security and Privacy self-review²: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ResourceTimingInitiatorInfo/explainer.md#securityprivacy-considerations
GitHub repo:https://github.com/w3c/resource-timing
Primary contacts: Guohui Deng(@guohuideng2024), Microsoft.
Organization/project driving the design: Microsoft and Google
This work is being funded by: Microsoft and Google
Incubation and standards groups that have discussed the design: github discussion: https://github.com/w3c/resource-timing/issues/263 WebPerf WG minutes: https://docs.google.com/document/d/1BxWvz6ymLAjl2-Ofy7rEsz5TaYzEdVDVIcv8NKZPdQU/edit?tab=t.0#heading=h.ewupa44m8fm7
Standards group(s) that you expect to discuss and/or adopt this work when it's ready: WebPerfWG
Multi-stakeholder feedback³:
- Chromium comments: planning to prototype this and work with the WebPerfWG.
- Mozilla comments: TBD
- WebKit comments: TBD
Major unresolved issues with or opposition to this design: Only one single "initiator" is reported for a resource. When JS fetches resource, multiple JS scripts may be involved. In this case, it's very desirable that we precisely define how we select the "initiator" so the Interoperability between different web browsers can be ensured.
[ x] I have reviewed the TAG's Web Platform Design Principles

Discussions

Discussed Jun 30, 2025 (See Github)

Yoav: This exposes resource timing dependency chaining on resource loading and uses URLs to do that. TRaditionally the URLs are not great for this b/c multiple URLs for the same resource loading at multiple times. In practice it is fine. Previous iteration added IDs. This ignores that URLs are good enough for this purpose and probably correct in 99% of the cases.

Martin: What happens if you get the wrong URL in this case?

Yoav: If you get it wrong and refer to the wrong resource, the conclusion is still the same. The UC here is for reporting and figuring out dependency loading chaining that you want to load thing you want, or modular preloads. If you get it wrong, it won't matter so that's a good point. Overall it looks good and reasonable.

Martin: Then shoul give a thumbs up. One sentence brief? And post it.

Yoav: Ack.

Comment by @yoavweiss Jul 3, 2025 (See Github)

We discussed this at the TAG breakout just now. This seems like a useful feature, so thanks for working on it!!

When it comes to API shape choice, URLs as "pointers" to other resources seems good enough in most cases, and even in cases where there are multiple resources with the same URL, distinguishing between them is not critical for the use-cases of the feature.