Mind helping us out?
Take our 4 question bug report survey—the avg time to complete is 43 seconds.

Intro to the Resource Timing API

In this post we're going to cover something you might not have heard of before but that could come in really handy--the JavaScript Resource Timing API. This is an API we rely on for User Bug Report that helps collect network request performance data.

user bug report screenshot network performance
Ever wanted to grab this data? *This* is your chance!

How it works

Loading a resource in the browser can be broken down into different phases--from initiating a request all the way to receiving the response. Most of the time you probably don't care about any of the phases in between. But when you have a performance bottleneck or are getting 404s in production, your opinion may change.


The phases of a network request.
Image by MDN is licensed under CC-BY-SA 2.5.

As you can see, your browser is tracking a lot more than just startTime and endTime.

How to use it

What's cool about the Resource Timing API is there is now a W3C standard which major, modern browsers are supporting. That means you can use this API without having to include any JavaScript libraries--pretty handy!

OK, so how do you actually use this API. From JavaScript, you can access the performance entries:

const resources = performance.getEntriesByType("resource");
console.log(resources[0]);
user bug report resource timing

You can see there's a lot of interesting info in here. A lot of it is self-explanatory. You're also going to see a lot of zeroes--some of the things tracked likely won't apply to every one of your requests. In this example I'm looking at the styles from our blog hosted on my machine. There are no redirects happening so you can see that both redirectStart and redirectEnd are both 0.

const timings = [];
for (const resource of resources) {
timings.push({
name: resource.name,
initiatorType: resource.initiatorType,
redirectTime: resource.redirectEnd - resource.redirectStart,
dnsTime: resource.domainLookupEnd - resource.domainLookupStart,
tcpHandshakeTime: resource.connectEnd - resource.connectStart,
secureConnectionTime: resource.connectEnd - resource.secureConnectionStart
responseTime: resource.responseEnd - resource.responseStart,
fetchUntilResponseEndTime: resource.responseEnd - resource.fetchStart
requestStartUntilResponseEnd: resource.responseEnd - resource.requestStart
startUntilResponseEnd: resource.responseEnd - resource.startTime
});
}
Grab the timing metrics you want and put them in an array.

With all of these fields there are multiple ways you can calculate how long a request takes. Which method you choose is going to be dependent on the context of your use case--or more likely, what you're debugging!

Request Size API

Many times going hand in hand with request times are resource sizes. This is something that can be surprisingly tricky to debug. Luckily for you the Resource Timing API is here to help.

  • transferSize: Size of the resource including header--in other words, the whole enchilada, rice and beans included.
  • encodedBodySize: Size of payload body before removing any encoding--the enchilada, rice and beans removed.
  • decodedBodySize: Size of payload body after removing any encodings--the enchilada, rice and beans removed with no Boom-Boom sauce (though I must argue that this defeats the purpose).

Before you go

If you want to track Resource Timing API data and other useful metrics about your app, you should check out our product here: https://www.userbugreport.com/. It's free to test out and it costs about as much as a pair of Chicka-Chicka Boom-Boom Enchiladas from Chuy's--and trust us when we say that User Bug Report has far fewer calories.

user bug report enchilada
Behold! The Chicka-Chicka Boom-Boom Enchilada.

Check out these additional resources for more info on the Resource Timing API.


Want to read more?
Sign up for our newsletter.