Guy Yogev

Dec 28, 2018

6 min read

Performance and DevTools

Performance and DevTools

A while back, I wrote about improving web pages performance JS optimizing. Finding which parts of the app require optimization, and what exactly is the source of the issue can be challenging.

Performance matters

First, why should we even care?

Why measure

As Adam Savage said

  • “The page loads at 5 seconds on a 1.5Mb download speed”.
  • “The on-scroll event handler takes 250ms to complete”
  • “To save network usage, our JS file should never exceed XX bytes.”

Measuring load time via audits

When analyzing a page, I like to start by running an audit. It shed light on the most common issues that have a very good effort-to-value ratio.

  • It can run on many devices/browsers.
  • Allows testing from different geographic locations.
  • Records screencasts and screenshots
  • Includes lighthouse audit.

DevTools overview

What are dev tools

In the past, debugging and profiling web pages was almost impossible. Breaking down how JS code runs, or how the page was rendered could be very hard to figure out.

Measuring performance via Chrome’s dev-tools

Chrome dev-tools offer many hidden gems. But before we dig into those, we must understand what they tell us. We should understand what concepts such as FPS or jank mean, and know-how the browser executes the code we feed into it. I highly recommend this tutorial

Real-time monitors

Real-time monitors help us understand how a user’s action affect the UI and its performance impact.

  • FPS Meter shows the frame rate over time and GPU usage.
  • Paint rectangles add a noticeable green flash effect to areas that are being repainted.
  • Performance Monitor tracks
  • CPU & memory usage
  • Counts DOM nodes, JS listeners, active assets (JS and CSS files) and iframes on the page
  • Count the number of style calculations and layouts per second.


Many developers use only a fraction of the console abilities, but we can travel pretty deeply down that rabbit hole.


While evaluating our app performance, it is important to simulate our end-user environment as closely as possible. Things might work smoothly at the office with our high-speed cable connection, but what about users with a slow G3 network?


Aside from the obvious features of file-viewer and debugger, source tab has some useful utils.


While the Performance monitors give us a bird’s eye view on the page behavior, this tab allows a much deeper inspection. It can record page interactions and display key metrics over time.

While recording, take into account dev-tools own performance overhead. We can minimize the noise by configuring the recording setting.
  • Network requests
  • Painted frames
  • Interactions (user-triggered events such as click/scroll…)
  • Main thread call stack


There are many routines we can apply for a deep dev-tools performance inspection. The basic process is

Blocking inefficient JS

At this routine

  1. Focus on performance warning indications.
  2. Zoom on the area, search for the JS call stack root, and it’s file.
  3. We find the file network request
  4. Block the request (or all requests) from the same domain

Improving UX with overrides

At this routine

  1. Slowly go over the recorded snapshots, looking for sharp changes.
  2. Find the faulty element on the DOM.
  3. Find the source file the applies the element CSS rules.
  4. Override the file.
  5. Make persistent changes to the local file.


That’s all we’ll cover at this post, however, dev-tools has a lot more to offer.
Mastering it can make a very powerful developer, and make a huge impact on the project bottom line.