You are viewing our old blog site. For latest posts, please visit us at the new space. Follow our publication there to stay updated with tech articles, tutorials, events & more.

Resource Timing API

0.00 avg. rating (0% score) - 0 votes on the address bar… enter… and yes we want our site to load in less than 2 secs ideally. If not, we are giving a bad experience to the users. Yes we all want our web applications to load in as much less time as we can. But with growing richness of the web applications, the web applications are becoming heavier and it has become very important to find ways to improve the speed of our web applications.

Improving speeds of website does not only mean minifying javascript files and compressing images, these days websites consists of a lot of external contents as well such as youtube videos, contents from CDN and these external contents need to be measured correctly as they might be responsible in increasing the load times. Also, any internal resource too could be responsible in increasing the load times
Resource Timing API is one such tool that allows us to effectively measure real time load times of resources in a web page.

What is Resource Timing API all about?

  • allows JavaScript mechanisms to collect complete timing information related to resources on a document
  • supports Chrome 25+, Internet Explorer 10-11, and Opera 15+
  • performance.getEntriesByType(“resource”) returns an array of resources present on a web page which can be iterated to get information of individual resource
  • Following are the properties which are used to obtain performance related information of any resource:
    • initiatorType—tells the type of timing resource e.g. “resource”, “navigation”, “mark”, and “measure”.
    • redirectStart– tells the start time in milliseconds of the redirect for the resource
    • redirectEnd– tells the end time in milliseconds of the redirect for the resource
    • fetchStart– tells the start time in milliseconds when the fetch for the resource started
    • domainLookupStart—tells the start time for the DNS lookup for the resource
    • domainLookupEnd-tells the end time for the DNS lookup for the resource
    • connectStart-tells the start time for TCP connection for the resource
    • connectEnd-tells the end time for TCP connection for the resource
    • secureConnectionStart– tells the time spent in handshaking with the https secure connection
    • requestStart -tells the start time for the request of the resource on server
    • responseStart-tells the start time for the response of the resource from the server
    • responseEnd-tells the end time for the response of the resource from the server
  • The figure below will give us more clear pictures about various phases in resource loading
  • Javascript example:
if ( !(‘performance’ in window) ||
       !(‘getEntriesByType’ in window.performance) ||
       !(window.performance.getEntriesByType(‘resource’) instanceof Array)
) {
       console.log(“api not supported”);
} else {
       window.onload= function() {
       var resources = window.performance.getEntriesByType(‘resource’);
       for(var obj in resources) {
       var list = ”;
       for(var properties in resources[obj]) {
       console.log( properties + ‘ ‘+ resources[obj][properties]);
//document.getElementsByTagName(“body”).innerHTML =        document.getElementsByTagName(“body”).innerHTML + list;

Key Points to Remember

  • For cross domain resources(such as CDNs) , the “Timing-Allow-Origin” header should be allowed and most CDNs do that
  • Responses with 304 status are not measured correctly
Having said so much good things about Resource Timing API, any portal would be enthusiastic to use Resource Timing API to optimize its page performance and so were we. On brainstorming we came up with these hurdles:
  1. There are average 1.5 Million hits each day on and lets assume each time 5 KB of data pertaining to page performance is sent to server. For 1.5 Million hits per day this data turns out to be huge and this would affect the bandwidth of the portal
  2. One solution to the problem stated above could be that, we do not track resources for every page and every user. This would bring down the data part, but then it would also nullify the concept of real time resource monitoring. And if we do not want real time monitoring, then why to go for Resource Timing API, synthetic monitoring(Webpage Test API) would suffice the requirement
We still are working on these hurdles and hopefully will come out with some solution soon.
Posted in Web Technology