We had introduced Real User Monitoring with which you can already get an overview of how the performance in each of your pages is.
However, only the page loadtime alone would not give the complete picture of your page loading in a browser. You have to deal with third party resources and AJAX calls that are part of your page, which will load asynchronously there by having an effect on the overall page loadtime.
The browsers that support Resource Timing API will be able to give you insight into these resource load timings as well.
What is Resource Timing API?
Resource Timing API is a W3C recommendation that provides methods to get the timing of each resource in a HTML document. In the below sections I will explain more in detail on how one can collect and analyse the data.
This document is still
work in progress, so please be sure to join the mailing list to get updates on any changes to this specification. Said that, since this specification is already implemented by majority of the browsers, I don’t foresee any major change to the complete specification.
So lets see how you can use this to improve your page performance.
window object contains
performance property through which all performance related APIs are exposed. The Resource Timing API is part of this. Using
getEntriesByType() method with argument “resource” you can get the Resource Timings.
var resourceList = window.performance.getEntriesByType("resource");
The return value of getEntriesByType is an array of
The Resource Timing objects could be
- XMLHttpRequest objects [XMLHttpRequest]
- HTML elements [HTML5] such as iframe, img, script, object, embed, and link with the link type of stylesheet
- SVG elements [SVG11] such as svg.
PerformanceResourceTiming interface extends the following attributes of the
PerformanceEntryinterface. There by, each resource entry has the following inherited properties:
- name - The resolved URL of the requested resource
- entryType - It is always set to fixed string “resource” in Resource Timing API
- startTime - It is DOMHighResTimeStamp with the time immediately before the user agent starts to queue the resource for fetching.
- duration - It is DOMHighResTimeStamp equal to the difference between responseEnd and startTime, respectively.
In addition to these properties, the
PerformanceResourceTiming interface provides the following read-only attributes:
- initiatorType - This is the most important attribute of the Resource Timing. With this you can find the type of the initiator.
- If it is an element, on getting, the initiatorType attribute must return a string with the same value as the localName of that element. e.g. iframe, img, script, object, embed, and link
- If it is a CSS resource then it holds the string
css. (for CSS resources downloaded using the
url()syntax — e.g.
- If it is an XMLHttpRequest object then it holds the string
- connectStart/connectEnd - The start and end time when the user agent establishes the connection to the server to retrieve the resource.
- domainLookupStart/domainLookupEnd - The time the user agent takes for domain name lookup for the resource.
- encodedBodySize - The size, in octets received by the client, of the payload body
- decodedBodySize - The size, in octets received by the client, of the message body
- fetchStart - The time before the user agent starts to fetch the resource.
- nextHopProtocol - The network protocol used to fetch the resource, as identified by the ALPN Protocol ID
- redirectStart/redirectEnd - The time f of the fetch that initiates the redirect.
- requestStart - The time before the user agent starts requesting the resource from the server or cache.
- responseStart/responseEnd - The time taken to receive the complete resource
- secureConnectionStart - When a secure transport is used, this attribute must return the time before the user agent starts the handshake process to secure the current connection.
- transferSize - The size, in octets received by the client, consumed by the response header fields and the response payload body.
- workerStart - The time before the user agent runs the worker required to service the request
The underlined attributes in above image may not be available for resources fetched from different origins.
The resource providers may return the
Timing-Allow-Origin HTTP response header to allow the User Agent to fully expose the values of attributes that would have been zero due to the cross-origin restrictions. If the header is absent, then the only available data is the total duration of the request.
Google, Facebook, Disqus already support Timing-Allow-Origin HTTP response header. And more and more resource providers support this header. So you have a good chance to get detailed resource timings, in the near future, for all your resources.
Handling Resource Objects
There are two more useful methods, using which you can control the resource objects
- clearResourceTimings - Using this you can clear the buffer that stores the current list of
- setResourceTimingBufferSize - This sets the maximum number of
PerformanceResourceTimingobjects. By default it is
150objects, if you don’t set it explicitly. When the array is full, then
onresourcetimingbufferfullevent is fired, where you can handle these objects as you want to.
Can I Use Resource Timing - shows that IE, Chrome and Firefox have that support, which is good news. However, Safari does not have this support as of now. So this makes it a challenge to handle the resource timing correctly at all browsers.
Get Started with Atatus
Ready to start Real User Monitoring (RUM) and speed up your web app with Atatus. It is just a one minute process. Sign up and install the two line script in all your pages and you are good to go. In no time you’ll be able to see how your pages are performing for all your users.
You can see which browsers run the slowest and for which countries the throughput is the lowest. Tweak your web app accordingly. Lastly, don’t forget that performance matters to your users.
Ready to optimize your site for real users? Sign up and deploy Atatus today.