An introduction to Chrome DevTools

This article is meant to provide a brief overview of each panel in Chrome DevTools. For more depth, I encourage you to read the official documentation.

With that said, DevTools is a fantastic resource that can easily boost productivity, but it can be a lot to take in at first.

What is DevTools? Where is DevTools?

Chrome DevTools is a set of web developer tools built directly into the Google Chrome browser. DevTools allows us to edit pages on-the-fly and diagnose problems quickly, which ultimately helps us build better websites, faster. There is so much to cover on this subject, so know that this article won’t cover everything, but it will highlight most of the core features. Let’s break down each tab or ‘panel’ and see what they have to offer.

First, we can open our DevTools by opening Google Chrome. With Chrome open, there are a few approaches we could take, depending on which panel we would like to open with.

Elements

If you want to work with the DOM or CSS, right-click an element on the page and select Inspect to jump into the Elements panel. Or press Command+Option+C (Mac) or Control+Shift+C (Windows, Linux, Chrome OS).

In the Elements panel we can:

• Inspect and edit any element in the DOM tree on the fly. To live-edit a DOM node, simply double-click a selected element in your DevTools and make the changes. Notice your changes reflect in the browser window. The DOM tree view shows the current state of the tree, but it may not match the HTML that was originally loaded.
• Use the Styles pane to view and change the CSS rules applied to any selected DOM element. To edit a name or value in the Styles pane, click on it, make your changes, and press Tab or Enter to save the change. All styles are editable, except the ones that are greyed out. By default, CSS modifications are not permanent, and changes are lost when the page reloads. Set up persistent authoring if you want to persist your changes between page loads.
• Use the Computed pane to view and edit a selected element’s box model. To edit the box model, click the value and make the desired change. The concentric rectangles contain the top, bottom, left, and right values for the current element’s padding, border, and margin properties. For non-statically positioned elements, a position rectangle is also displayed, containing the values of the top, right, bottom, and left properties. For position: fixed and position: absolute elements, the central field contains the actual offsetWidth × offsetHeight pixel dimensions of the selected element.

The Elements panel also has an Accessibility pane which is used to investigate the accessibility properties of the currently-selected element. We can also inspect the contrast ratio of text elements in the Color Picker to ensure that they’re accessible to users with low-vision impairments or color-vision deficiencies.

For more on the Elements panel, start here.

Console

If you want to see logged messages or run JavaScript, press Command+Option+J (Mac) or Control+Shift+J (Windows, Linux, Chrome OS) to jump straight into the Console panel.

To log a message, insert an expression like

console.log(‘Hello, Console!’)

into your JavaScript. When the browser executes your JavaScript and sees an expression like that, it knows that it’s supposed to log the message to the Console. Logging messages can be extremely useful to make sure that your code is executing in the right order, or to inspect the values of variables at a certain moment in time.

The Console is also a REPL, so you can type and run JavaScript directly in the Console to interact with the page that you’re inspecting, or just to test out something like a new built-in method you just discovered.

For more on the Console panel, start here.

Sources

The Sources panel UI consists of 3 parts:

1. (Upper-Left) The File Navigator pane. Every file that the page requests is listed here.

2. (Upper-Right) The Code Editor pane. After selecting a file in the File Navigator pane, the contents of that file are displayed here.

3. (Bottom-Half) The JavaScript Debugging pane. This includes various tools for inspecting the page’s JavaScript. If your DevTools window is wide, this pane is displayed to the right of the Code Editor pane. Debugging with breakpoints can be a powerful and time saving skill, however it is beyond the scope of this article.

If you’re interested in learning more on that subject, start here.

We can also use the Sources panel to keep any changes made in DevTools, and keep those changes across page loads. This works by specifying a directory where DevTools should save changes. Then, when we make those changes in DevTools, DevTools saves a copy of the modified file to the specified directory. When we reload the page, DevTools serves the local, modified file, rather than the network resource.

To set up Local Overrides:

1. Open the Overrides tab.

2. Click Setup Overrides.

3. Select which directory you want to save your changes to.

4. At the top of your viewport, click Allow to give DevTools read and write access to the directory.

5. Make your changes!

Some things to note:

• DevTools doesn’t save changes made in the DOM Tree of the Elements panel. Edit HTML in the Sources panel instead.
• If we edit CSS in the Styles pane, and the source of that CSS is an HTML file, DevTools won’t save the change. Edit the HTML file in the Sources panel instead.

For more on the Sources panel, start here.

Network

The most common use cases for the Network panel are:

• Making sure that resources are actually being uploaded or downloaded as expected.
• Inspecting the properties of an individual resource, such as its HTTP headers, content, size, and so on.

To view the network activity that a page causes, reload the page. The Network panel logs all network activity in the Network Log.

Each row of the Network Log represents a resource. By default, the resources are listed chronologically. The top resource is usually the main HTML document. The bottom resource is whatever was requested last.

Each column of the Network Log represents information about a resource:

• Status displays the HTTP response code.
• Type displays the resource type.
• Initiator displays what caused a resource to be requested. Clicking a link in the Initiator column takes you to the source code that caused the request.
• Time displays how long the request took.
• Waterfall displays a graphical representation of the different stages of the request. Hover over a Waterfall to see a breakdown.

We can also click the timeline above the columns to limit our resource info to a certain point of time. In addition, we can filter our results by selecting certain types or by using the search bar in the filter section directly above the timeline.

Furthermore, the columns of the Network Log are configurable. You can hide columns that you’re not using, or show columns that are hidden by default. Do this by right clicking one of the columns and selecting/deselecting an item from the dropdown that appears.

Lastly, the Network panel can also be used to simulate a slower internet connection. Try this out by clicking the Online panel in the upper-right corner and selecting a slower connection.

There is much more that can be done with the power of the Network tab. For more information, start here.

Performance

The Performance panel is used to analyze, you guessed it, performance. You can also click the settings gear icon in the upper-right to throttle the CPU, thus simulating a mobile device with much weaker CPU than the typical desktop computer.

To analyze performance, first make sure that the Screenshot box next to the settings gear is checked. Then simply click the record button to start a recording. If you want to record the page load, click the reload button underneath.

Once you’ve stopped recording, DevTools processes the data, then displays the results.

Near the top we have the FPS (frames per second) bar, which is the standard metric for measuring the performance of any animation. Whenever you see a red bar above the FPS, it means that the frame rate dropped low enough to potentially harm the user experience. In general, the higher the green bar, the higher the FPS.

Below the FPS chart is the CPU chart. The colors in the CPU chart correspond to the colors in the Summary tab, at the bottom of the Performance panel. If the CPU chart is full of color, the CPU was probably maxed out during the recording. Whenever you see the CPU maxed out for long periods, it’s a cue to find ways to do less work.

Hover your mouse over the FPS, CPU, or NET charts. DevTools shows a screenshot of the page at that point in time. Move your mouse left and right to replay the recording. This is called scrubbing, and it’s useful for manually analyzing the progression of animations.

In the Frames section, hover your mouse over one of the green squares. DevTools shows you the FPS for that particular frame.

In the Main section we can click and scroll to zoom in on a particular event. As you do this you may notice the Summary section update.

For a clean slate, click the clear button near the top left, under the panel options.

For a more in depth look at analyzing performance, start here.

Memory

The Memory panel can be used to find memory issues that affect page performance, including memory leaks, memory bloat, and frequent garbage collections.

Memory issues are important because they are often perceivable by users. Here are some ways users can perceive memory issues:

• A page’s performance gets progressively worse over time. This is possibly a symptom of a memory leak. A memory leak is when a bug in the page causes the page to progressively use more and more memory over time.
• A page’s performance is consistently bad. This is possibly a symptom of memory bloat. Memory bloat is when a page uses more memory than is necessary for optimal page speed.
• A page’s performance is delayed or appears to pause frequently. This is possibly a symptom of frequent garbage collections. Garbage collection is when the browser reclaims memory. The browser decides when this happens. During collections, all script execution is paused. So if the browser is garbage collecting a lot, script execution is going to get paused a lot.

The quickest way to get started here is by taking a Heap snapshot. We can do this by clicking the record button in the upper-left corner. Once the snapshot records, we get the overall size of the JavaScript objects that can be reached. After selecting the loaded snapshot, a table appears with 5 new columns.

Here is a short overview of the columns in this table:

• Constructor: The JavaScript function used to construct the objects.
• Distance: The distance from the root. The greater the distance is, the longer the object takes to load and process.
• Objects Count: The amount of objects created by the specified constructor.
• Shallow Size: The shadow size of every object that was created via a particular constructor.
• Retained Size: The greatest retained size of a set of objects.

Above these columns we can switch views. Summary is selected by default, but we can also select the Comparison, Containment and Statistics view.

• Comparison view allows you to find differences between the snapshots you have taken. This view is only available if you have taken more than one snapshot.
• Containment view allows you to explore heap contents, which are also color coded.
• Statistics view displays a circular chart, which shows how much memory each type of object that is present takes up overall.

For a more in depth read on the Memory panel, start here.

Application

The Application panel is split between 5 panes: Application, Storage, Cache, Background Services, and Frames.

• The Application pane can be used to view the web app manifest related to progressive web apps, view and debug service workers which the page might be using, view storage stats, and clear all forms of storage, including cookies.
• The Storage sub-panel can be used to view and edit local storage, session storage, indexedDB databases, webSQL databases, and to view per-origin cookie information and related properties.
• The Cache pane can be used to view cache storage as well as to view information on the application cache.
• The Background Services sub-panel can be used to view information regarding Background Fetch, Background Sync, Notifications, Payment Handler, Periodic Background Sync, and Push Messaging.
• Finally, the Frames sub-panel allows you to view frames and other resources which a page may be using, including iframes.

For a deeper dive on the Application panel, start here.

Security

The Security panel opens to an overview that starts by stating whether or not the page is secure. If a status of Mixed Content is returned, that means that the main origin of a page is secure, but the page requested resources from non-secure origins. Mixed content pages are only partially protected because the HTTP content is accessible to sniffers and vulnerable to man-in-the-middle attacks.

Additionally, we can click View Certificate to quickly inspect the main origin’s certificate.

The Security overview also provides security information related to the page’s connection and resource status.

For more information on the Security panel, start here.

Lighthouse

Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. To run an audit, select Audit. This will take roughly a minute to complete, and when done will provide a report on the page for performance, accessibility, progressive web apps, SEO and more. From there, use the failing audits as indicators on how to improve the page. Each audit has a reference doc explaining why the audit is important, as well as how to fix it.

Lighthouse can also be used from the command line, as a Node module, or from a web UI.

For more on Lighthouse, start here.