Random thoughts & observations

From the mundane to the profound and everything in between here’s what’s rocking our world

Measuring Javascript performance and debugging with browser inspector tools

Posted: September 4, 2015
Written by: Saints At Play
Category: Javascript

As JavaScript has become a central pillar of front-end web development, thanks to modern browser support, the tools we need to measure how our scripts are performing have become increasingly important.

In this article we're going to take a look at some of these tools that are available directly within the Google Chrome browser...

Logging Output

The browser console log is your friend.

Any front-end developer who's acquainted with basic JavaScript will be familiar with using the console.log() method. By adding this method into our scripts we can display unobtrusive messages within the browser console during the development/testing phases of a project, for example:

var countryNames = ['Australia', 
for(var j = 0; j < countryNames.length; j++)
 console.log('Country is: ' + countryNames[j]);

// Returns 
Country is: Australia
Country is: Barbados
Country is: Canada
Country is: Denmark
Country is: England
Country is: France
Country is: Germany
Country is: Holland

Definitely better than the 'good' old days of using alert boxes to test/return back our data right? ;)

Accessing dynamic objects

The console.dir() method allows the developer to display a list of all the properties associated with a specified JavaScript object making the debugging and inspection of dynamically generated objects (I.e. when parsing external data into custom objects for later read/write operations) quicker and easier to accomplish.

Simply enter the name of the generated object between the parentheses of the console.dir() method like so:


And the console will render an expandable/collapsible tree like representation of the object and its associated key/value pairs similar to the following:

Console directory method results‚Äč

If, for example, you're parsing JSON returned from an Ajax call then this console method is great for learning more about and investigating the structure of that returned data.

Measuring execution times

With browser resources far from limitless (and this becomes even more critical on mobile devices) it's important to check for slow execution times and potential bottlenecks in processing our scripts.

There are a number of different approaches we could use to measure execution times:

  • console.time()/console.timeEnd()
  • console.profile()/console.profileEnd()
  • performance.now()

We'll take a look at using the performance interface however as this is specifically designed to measure timing-related performance.

Say, for example, that we wanted to measure the length of time taken for a loop operation to complete we could use the now() method of the Performance interface (which measures time to a thousandth of a millisecond) like so (note: you wouldn't want to perform 200,000 iterations in a real-world script as this would be hugely detrimental to performance - this is purely for demonstration purposes!):

var startTime = performance.now(); 
for(var i = 0; i < 200000; i++)
  console.log('Number ' + i); 
var endTime  = performance.now(); 
console.log('Took ' + Math.round((endTime - startTime)/1000) + ' seconds');

Which, in tests ran on Mac OS X 10.9.5 running the Google Chrome browser version 44.0.2403.157 (64-bit), resulted in the following console output:

Took 27 seconds

As always with any JavaScript technology browser support is a consideration. Those browsers that support the performance.now() method are:

  • Internet Explorer 10+
  • Google Chrome 24.0+
  • Firefox 15.0+
  • Opera
  • Safari

Analysing application flow

With all the best programming intentions in the world our scripts don't always perform exactly as expected. Sometimes the execution flow seems contrary to what we've coded and debugging this to try and figure out what's going on can quickly become a headache.

This is where the use of breakpoints can pay dividends.

To start exploring the use of breakpoints crack open the Google Chrome Inspector and navigate to the Sources tab. You'll notice that this displays a list of all assets related to the web page you are currently viewing, allowing you to select and analyse those assets like so:

Google Chrome Inspector Sources module displaying compressed JavaScript code

Notice that the JavaScript code in the above screenshot is minified but if we click on the {} braces located at the bottom left-hand side of the middle column we can unpack the JavaScript like so:

Google Chrome Inspector Sources module displaying uncompressed JavaScript code

Pretty cool huh?

In our displayed JavaScript we can establish a breakpoint (or a series of breakpoints) by clicking on the number of the line(s) where the script functionality that we want to be triggered is located.

If we then reload our page and start interacting with elements in the DOM we'll start to see the script pausing at where these breakpoints are being executed:

Google Chrome Inspector displaying breakpoint being triggered during form submission

In the above example, we're executing some validation logic to be triggered on submission of a specific form. When the breakpoint is triggered the line of code where that breakpoint is set is highlighted, events in the DOM and the normal behaviour of the page are paused and we have access to information about scopes and the event or method that triggered the breakpoint.

That's a pretty detailed view of what is occuring during the execution logic at specific points in the code and, furthermore, like the rest of the Inspector tools, it's free!

To remove a breakpoint simply right click on the breakpoint and select Remove Breakpoint from the contextual menu:

Removing a breakpoint in the Google Chrome Inspector

Breakpoints are a fantastic way to inspect the application logic flow and understand where potential bugs, issues or bottlenecks in performance may be occurring.

If you're not already using breakpoints you really should think about doing so - they're deceptively useful.

Network requests

No matter how well we craft our scripts our websites/applications will always, to some extent, be at the mercy of network conditions. If there are any potential issues with script loading times and/or http requests, that aren't immediately obvious, we can use the browser inspector module to analyse all network requests that are being made by our websites/applications.

In the following screenshot we use the Google Chrome Network Inspector to display the results of All http requests that have been made by our website:

Google Chrome network inspector displaying website resources retrieved via http request

This provides information on the type of http request (I.e. GET, POST, PUT etc), the http status code returned (I.e. 200 - OK, 304 - Not Modified etc), the type of asset, where the request for the asset initiated from, the size of the returned asset, time taken for the asset to be retrieved and a Timeline representation of the retrieval of those requested assets.

We can take these results and filter them down by asset type, such as, for example, XHR objects returned from Ajax calls:

Google Chrome network inspector displaying results of Ajax requests only

From here we can select the listed result(s) and find detailed information about request/response headers that are sent/received by the browser along with a preview of the returned data (in this case parsed JSON):

Google Chrome network inspector displaying results of Ajax Call for a particular URL

Although the Network Inspector might not highlight a bug in your JavaScript code directly it can, however, provide detailed information on network requests and help determine if there are any issues with those from the server and/or client-side.

In closing

Thanks to the continuing evolution of modern browsers we now have a range of different tools to test and debug our JavaScript that were previously unavailable. This makes analysing the efficiency of our scripts, tracking bugs, determining execution times and locating issues with http requests - to name but a handful of potential needs - so much easier to accomplish than at any other time in web development history.

We could, of course, have listed unit testing here as a way of determining whether or not your scripts are performing as expected but this article is geared towards browser based development tools only.

So, whatever your coding, be aware of the availability of testing and debugging tools offered by all of the latest modern browsers including even, yes....Internet Explorer! :)

« Return to Posts


There are no comments

Posting comments after three months has been disabled.