Learn how to accurately measure the performance of your JavaScript application using the browser’s Performance APIs (now, mark and measure).

Measuring the time it takes to execute a function is always a good idea to prove that some implementation is more performant than the other. It’s also a good way to ensure that performance didn’t suffer after some change and to track down bottlenecks.

Good performance contributes to a good user experience. And a good user experience makes users come back. This research for example shows, 88% of online consumers are less likely to return after a poor user experience due to performance issues.

That’s why it’s important to be able to recognize bottlenecks in your code and measure the improvements. Especially when developing JavaScript for the browser it’s important to be aware that every line of JavaScript you write can potentially block the DOM since it’s a single-threaded language.

In this article, I will explain how you can measure the performance of your functions and what to do with the results, you get from them.

The functions I mention here are good for debugging JavaScript functions at a low level. If you want to make sure that your application stays fast, even after more features get added, consider the implementation of a performance budget.

Performance.now

The performance API provides access to the DOMHighResTimeStamp through its function performance.now(), which returns the time passed since the page loaded in milliseconds, with a precision of up to 5µs in the fractional.

So in practice you need to take two timestamps, save them in a variable and then rest the second from the first one:

const t0 = performance.now();
for (let i = 0; i < array.length; i++) 
{
  // some code
}
const t1 = performance.now();
console.log(t1 - t0, 'milliseconds');

Output (Chrome):

0.6350000001020817 "milliseconds

Output (Firefox):

1 milliseconds

Here we can see that the result in Firefox is quite different from Chrome. This is because Firefox, as of version 60, is reducing the precision of the performance API to 2ms. You can find more information about this at the end of this post.

The performance API offers much more functionality than only returning a timestamp. It’s able to measure navigation timing, user timing, or resource timing.

For our use-case, however, we only want to measure the performance of a single function so a timestamp will be enough.

Isn’t that the same as Date.now?

Now you could think, hey, I could also use Date.now for that.

Yes you can, but that has drawbacks.

Date.now returns, in milliseconds, the time passed since the Unix epoch (1970-01-01T00:00:00Z) and depends on the system clock. This doesn’t only mean that it’s not as precise, but it’s also not always incrementing. Here’s how a WebKit engineer (Tony Gentilcore) explains it:

“Perhaps less often considered is that Date, based on system time, isn’t ideal for real user monitoring either. Most systems run a daemon that regularly synchronizes the time. It is common for the clock to be tweaked a few milliseconds every 15-20 minutes. At that rate about 1% of 10 second intervals measured would be inaccurate.”

#javascript #programming #developer