Performance and DevTools

Guy Yogev
Guy Yogev
Dec 28, 2018 · 6 min read

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.

At this post, I’ll try to introduce some tools and routines that can help pinpoint the issue, and quickly testing our solution.

Performance matters

First, why should we even care?

Well, retaining users is hard. This day’s users expect things to be fast and smooth. Google’s study shows even a few seconds of loading time lag can make the session duration drop and bounce rate climb.

Even if we managed to load the page fairly quickly, bad UX is not easily forgiven.

If we can retain users, we lose business. In short Performance == Money.

Why measure

As Adam Savage said

Remember kids, the only difference between screwing around and science is writing it down.

A user “feels” the load time is long, or scroll is sluggish. Measuring allows us to translate such “feelings” into hard metrics. In other words, it shifts us from the qualitative discussion to a quantitative one.

Measurements allow us to define the problem

  • “The page loads at 5 seconds on a 1.5Mb download speed”.
  • “The on-scroll event handler takes 250ms to complete”

And even better, to define standards we wish to keep (maybe even protect by CI automation)

  • “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.

Chrome dev-tools Audit tab can generate a Lighthouse report, but I find webpagetest more powerful because

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

The downside of an audit is that it only covers the page load time. It can’t track issues that require user interaction.

Once low handing fruits such as cache, minification, and compression are cleared, we can attack finer issues with dev-tools.

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.

Developers started to create developer-tools that would be attached to the browser as a plugin/extension, that would add functionality to the native browser (i.e. FireFox’s FireBug).

Those tools allow developers to observe how the browser runs the code, and more importantly, change it and see the impact immediately, making the debug cycle very short.

This day’s such dev tools are embedded natively in all major browsers.

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

Tips 1. Open dev-tools with cmd+shift+I 2. Quickly navigate between tools via cmd+shift+P

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.

The next clip demonstrates those tools in action. See how hovering over elements on the page shows which parts of the page are being repainted, and the impact on the monitors.

Console

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

Setting the logs level to verbose will print common performance violations warnings that are detected by the browser.

For example at the next screenshots, the last log entry shows a setTimeout callback took to long to complete.

Image for post
Image for post

Network

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?

Network tab allows us to do just that — test and monitor the page under simulated network configuration.

Another nice feature is Coverage that exposes dead code that can & should be deleted. Some teams like to define a network budget (i.e. JS Kb limit). Such limits can be enforced by CI automation).

Request blocking allows blacklisting specific files/domains. For example, files we can block files with low coverage, and see its impacts immediately.

Source

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

Network shows all resources that were loaded by the page.

Snippets allow creating persistent code blocks, which can save repeated typing while debugging from the console.

In my view, the most powerful tool is overrides, which allows loading a local copy of a resource from our file system. This allows us to use dev-tools as an IDE. It is an extremely fast way to test code changes, no need to go through a full build-deploy cycle.

Performance

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.

The amount of data can be overwhelming. Without understanding the pixel pipeline discovering the source of performance issue is like finding a needle in a haystack.

The matter is well covered at this doc, I’ll provide a short overview.

Image for post
Image for post

At the top, we’ll find the recording settings. Just like at the network tab, we can throttle CPU, which can help surface performance issues.

While recording, take into account dev-tools own performance overhead. We can minimize the noise by configuring the recording setting.

Below it, we’ll find FPS, CPU and network usage.

Next snapshots (if recorded), and a deeper breakdown of

  • Network requests
  • Painted frames
  • Interactions (user-triggered events such as click/scroll…)
  • Main thread call stack

We can dive deeper into a single frame paint process, view a layers breakdown and see the frame paint strokes via the paint profiler

Image for post
Image for post

Examples

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

Here are a few examples.

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

At the next screencast, we pinpoint pub_ads_impl.js script as a bottleneck and block its domain.

Running a performance test again shows load time improve at about 67% (!!!) dropping from 13 seconds to 4, and the performance warning has disappeared.

Image for post
Image for post

Now that we contained the issue, we can decide how to handle it (remove, replace, delay, move to service worker…)

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.

At the next screencast, we see the page height changes due to a banner with an undefined height. Tightening the banner CSS class eliminates the issue.

Summary

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.

Originally published at https://guyogev.com on December 28, 2018.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store