Open lencioni opened 6 years ago
Computing the critical path is difficult in general, though there may still be value to your proposal.
An example of why computing the critical path is extremely difficult: N JS files from N different origins can all insert script tags into the main document, which load resources from random other origins.
It's difficult to associate the resource loads from script injected into the document with the origin which injected the script.
This is a fairly simple example: there are plenty of common more complicated patterns which make computing the critical path complicated.
Indeed! Perhaps we can have a solution that makes a good effort as a starting point, as long as the unclear or broken paths are indicated as such? It seems that even a partial or fragmented graph could still be useful, especially if the unknowns were indicated.
I've been thinking about how we might improve our RUM monitoring and I got to thinking about critical path length. Resource Timing seems like it has almost all of the information one might need to determine the critical path length, or even any resource path length, but not quite.
PerformanceResourceTiming
already hasinitiatorType
, but that only tells you the category of resource that initiated the request.Perhaps some of this could be inferred by piecing together disparate timing information, but it would be nice if we had access to something a bit more structured. Would it make sense to add an
initiator
reference toPerformanceResourceTiming
to enable this kind of analysis? Or, maybe this is already possible in a different way?Sorry if this is not the right venue for this, I'm new around here. 🙋