When discussing performance metrics, you mentioned utilizing Navigation Timing, identifying User Timing with the use of performance.mark(), but overlooked the valuable Resource Timing API. All three components are integral parts of the overarching Performance Timing API.
Navigation Timing primarily focuses on measuring the loading time of a homepage or application, while the Resource Timing API offers insights into the loading process of individual asynchronously loaded resources in relation to navigation times.
Consider this: Asynchronously loaded files lack a DOM environment to execute! Consequently, resource timing lacks certain DOM properties. However, the starting point remains consistent with that of navigation timing:
https://i.sstatic.net/jvgzk.png
One key property within the Performance Timing API is startTime, which holds significant importance. Each asynchronous call possesses its own unique startTime, with a value of 0 for documents and >0 ms for JavaScript files and other resources.
The startTime serves as the initial timestamp, marking the commencement of resource loading by the browser. In resource timing, startTime aligns with either fetchStart or redirectStart (if not zero) when measuring a resource's timing.
Instances such as CSS or image resources lack both DOM interaction and execution capabilities. Whereas resources with a .js extension engage in JavaScript execution, allowing for user timing through performance.mark() actions, as previously noted.
- Can the NavigationTimingAPI be used on asynchronous calls?
The answer lies somewhere between yes and no. Resource Timing automatically logs relevant marks that can be compared against Navigation Timing data, facilitating useful analyses. Although there is potential for utilizing NavigationTimingAPI on asynchronous calls, it should be noted that measuring the index.html (navigation) differs from tracking async calls (resources):
Simply switch from
performance.getEntriesByType("navigation")
to
performance.getEntriesByType("resource")
.