GeezerVison is showing developer.mozilla.org — PerformanceResourceTiming - Web APIs | MDN
PerformanceResourceTiming
Baseline
Widely available
*
This feature is well established and works across many devices and browser versions. It’s been available across browsers since September 2017.
* Some parts of this feature may have varying levels of support.
The PerformanceResourceTiming interface enables retrieval and analysis of detailed network timing data regarding the loading of an application's resources. An application can use the timing metrics to determine, for example, the length of time it takes to fetch a specific resource, such as an XMLHttpRequest, <SVG>, image, or script.
The interface's properties create a resource loading timeline with high-resolution timestamps for network events such as redirect start and end times, fetch start, DNS lookup start and end times, response start and end times, and more. Additionally, the interface extends PerformanceEntry with other properties which provide data about the size of the fetched resource as well as the type of resource that initiated the fetch.
The properties of this interface allow you to calculate certain resource timing metrics. Common use cases include:
- Measuring TCP handshake time (
connectEnd - connectStart)
- Measuring DNS lookup time (
domainLookupEnd - domainLookupStart)
- Measuring redirection time (
redirectEnd - redirectStart)
- Measuring interim request time (
firstInterimResponseStart - finalResponseHeadersStart)
- Measuring request time (
responseStart - requestStart)
- Measuring document request time (
finalResponseHeadersStart - requestStart)
- Measuring TLS negotiation time (
requestStart - secureConnectionStart)
- Measuring time to fetch (without redirects) (
responseEnd - fetchStart)
- Measuring ServiceWorker processing time (
fetchStart - workerStart)
- Checking if content was compressed (
decodedBodySize should not be encodedBodySize)
- Checking if local caches were hit (
transferSize should be 0)
- Checking if modern and fast protocols are used (
nextHopProtocol should be HTTP/2 or HTTP/3)
- Checking if the correct resources are render-blocking (
renderBlockingStatus)
By default only 250 resource timing entries are buffered. For more information see the resource buffer sizes of the Resource Timing guide.
Timing information for a cross-origin resource is restricted unless the resource passes the Timing-Allow-Origin check.
This applies to the following properties, which return 0, an empty string, or an empty array by default when loading a resource from an origin other than the one of the web page itself: redirectStart, redirectEnd, workerStart, domainLookupStart, domainLookupEnd, connectStart, connectEnd, secureConnectionStart, requestStart, firstInterimResponseStart, responseStart, finalResponseHeadersStart, nextHopProtocol, transferSize, deliveryType, and serverTiming.
Even a resource that passes the CORS check still needs Timing-Allow-Origin to expose them.
For example, to allow https://developer.mozilla.org to see resource timing information, the cross-origin resource should send:
http Timing-Allow-Origin: https://developer.mozilla.org
Other properties describe the response itself rather than its timing, and depend on the CORS check instead of the Timing-Allow-Origin check.
The contentType, encodedBodySize, decodedBodySize, and responseStatus properties return 0 or an empty string for cross-origin resources unless the resource was requested in cors mode and passed the CORS check.
Frame navigations, such as an <iframe> loading its document, don't use CORS, so their body sizes are exposed only for same-origin frames loaded without cross-origin redirects.
The transferSize property depends on both checks: it's 0 without Timing-Allow-Origin, and it excludes the body size if the resource doesn't pass the CORS check.
If the document in a cross-origin <iframe> fails the Timing-Allow-Origin check, the browser reports a fallback entry.
In this entry, responseEnd is the time at which the iframe finished loading, including its subresources.
See Cross-origin iframes for more information.
Example using a PerformanceObserver, which notifies of new resource performance entries as they are recorded in the browser's performance timeline. Use the buffered option to access entries from before the observer creation.
js const observer = new PerformanceObserver((list) => {
list.getEntries().forEach((entry) => {
console.log(entry);
});
});
observer.observe({ type: "resource", buffered: true });
Example using Performance.getEntriesByType(), which only shows resource performance entries present in the browser's performance timeline at the time you call this method:
js const resources = performance.getEntriesByType("resource");
resources.forEach((entry) => {
console.log(entry);
});
|
