Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource initiator information to enable creation of dependency trees #263

Open
yoavweiss opened this issue Apr 1, 2021 · 2 comments
Open
Projects

Comments

@yoavweiss
Copy link
Contributor

many years ago we talked about extending the initiator information that resource timing exposes to enable creation of dependency trees from RUM data.
Those dependency trees could then enable better understanding of the resource loading of the page in the wild, and enable interesting analysis and optimizations.

For example, understanding which resources are responsible for the loading of others, can result in understanding that early discovery of the resources can speed up others, and encourage developers to preload them.

@marcelduran
Copy link

Here's the use case involving ServiceWorker I mentioned during last call:

  • A SW (sw.js) controlled page has a script foo.js that requests /bar
  • SW intercepts all requests via the fetch handler
  • Several pages might be open requesting the same /bar
    Question: Who should be considered the initiator when a SW intercepts requests?
  1. sw.js ?
  2. foo.js ?

I believe we have 2 contexts here: the page and the SW. IMO, regardless where RT entries are queried from, both should show foo.js as initiator. Reason being the fact that with a SW intercepting all requests, all entries would be pointing to sw.js which ultimately does not help building an accurate dependency tree.

@nicjansma
Copy link
Contributor

Some thoughts on scenarios that a more accurate dependency tree could enable:

  • The data would enable a RUM version of the RequestMap tool via @simonhearne
  • RUM tools could use it to enhance their analysis, such being able to more accurately bucket page weight costs by first- and third- party libs, or suggest which third-parties to cut and their full costs
  • CDNs could probably use this information to make smarter decisions about pre-fetching or pre-loading content for visitors, i.e. only load X CSS if Y JavaScript was loaded
  • Security products could better backtrace rogue requests

Would definitely love to see if this is a possibility!

@yoavweiss yoavweiss added this to Triage in Triage May 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants