guohuideng@microsoft.com or guohuideng2024
Please join the discussion at: https://github.com/w3c/resource-timing/issues/263
yashjoshimail@gmail.com put up 4 CLs (wpt tests, and implementation for the cases where the initiators are html and javascript) and a design doc . More discussion can be found here and here.
To expose the dependency of the resources from RUM (real user monitoring) data.
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.
Chrome devtool exposes an attribute initiator for a similar purpose.
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.
This document proposes that we extend PerformanceResourceTiming to enable the collection of resource dependency data from real users.
The idea was brought up in year 2021. To sum up the discussion, quoting from nicjansma@, a more accurate dependency tree from RUM can help:
A new field initiatorUrl will be added to the PerformanceEntry returned by PerformanceResourceTiming. initiatorUrl is the url of the resource that triggered the fetch of the current resource.
const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log("name: ", entry.name, "initiatorUrl: ", entry.initiatorUrl);
});
});
observer.observe({ type: "resource", buffered: true });
/*
sample output:
name: url_to_apple, initiatorUrl: ....
name: url_to_orange, initiatorUlr: url_to_apple
Then we conclude that resource "apple" triggered the fetch of the resource "orange".
*/
initiator info valuesAn empty initiatorUrl indicates the initiator info is missing. There are a number of possibilities discussed below.
initiator may not exist.A main page can be loaded according to the user navigation. For the main page, initiator doesn't exist.
Resources can be cached, or handled by service workers, instead of being downloaded from network. They still appear in PerformanceResourceTiming. Such resources are not part of the resource dependency tree, and they are not relevant to the content delivery optimization.
initiatorUrl is empty unless the resource is actually downloaded from network.
There are a number of advantages to this approach.
It's easier to consume the output to construct the resource dependency tree: Only the PerformanceResourceTiming entries with valid initiator info are considered. No extra filter is needed.
It avoids overhead when the resources are loaded fast.
It simplifies implementation.
initiator Info.When the initiator info is missing for some resources, the partial resource dependency information is still useful. Therefore, a UA can release a partial initiator info implementation and make improvements later.
It's expected that some UAs skip resources for the following reasons: rarity of such resources; excessive complexty in implementation; resources being fetched with deprecated HTML/CSS/JS features.
Using an Id obscures the target resource. We must provide the Id for all the resources so that the Ids can be interpreted. This approach makes it more complicated to consume the information.
PerformanceResourceTiming EntryIt would be effortless to find the initator resource. However, the initiator PerformanceResourceTiming entry may be garbage collected already when it's reported as an initiator resource. So it alone is not a reliable presentation.
The "initiator" concept has been implemented in a number of places. Most noticeably, it's reported in Chrome Devtool "network" tab. However, there is a lack of a clear specification on how the initiator should be determined.
For interoperability, it's very desirable to specify how the initiator resource is determined.
TBD.
All the attributes proposed to be exposed are behind CORS check. Timing-Allow-Origin doesn’t expose these values.
- What information does this feature expose, and for what purposes?
The new fields from PerformanceResourceTiming expose what resource triggered the fetch of what resource. Collected from RUM (real user monitoring), they can help the web sites and CDN optimize content delivery, and help security products track down rogue content.
- Do features in your specification expose the minimum amount of information necessary to implement the intended functionality?
Yes
- Do the features in your specification expose personal information, personally-identifiable information (PII), or information derived from either?
No.
- How do the features in your specification deal with sensitive information?
It does not deal with sensitive information.
- Does data exposed by your specification carry related but distinct information that may not be obvious to users??
No.
- Do the features in your specification introduce state that persists across browsing sessions?
No.
- Do the features in your specification expose information about the underlying platform to origins?
No.
- Does this specification allow an origin to send data to the underlying platform?
No.
- Do features in this specification enable access to device sensors?
No.
- Do features in this specification enable new script execution/loading mechanisms?
No.
- Do features in this specification allow an origin to access other devices?
No.
- Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No.
- What temporary identifiers do the features in this specification create or expose to the web?
No.
- How does this specification distinguish between behavior in first-party and third-party contexts?
No distinction.
- How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
No difference.
- Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes.
- Do features in your specification enable origins to downgrade default security protections?
No.
- What happens when a document that uses your feature is kept alive in BFCache (instead of getting destroyed) after navigation, and potentially gets reused on future navigations back to the document?
When navigating back to a document that has been alive in BFCache, some resources would be loaded from cache instead of network. The initiatorUrl field would be empty in the corresponding PerformanceResourceTiming entries. However, whether a resource is loaded from cache or network is already implicated by a collection of content sizes in PerformanceResourceTiming. Therefore, no new information is exposed because of this behavior.
- What happens when a document that uses your feature gets disconnected?
No difference.
- Does your spec define when and how new kinds of errors should be raised?
No new errors should be raised.
- Does your feature allow sites to learn about the users use of assistive technology?
Not directly.
- What should this questionnaire have asked?
Nothing else.