Mastering Chrome Developer Tools

Jon Kuperman begins his course on the Chrome Developer Tools by sharing a brief history of browser developer tools. Years ago developers relied on viewing the page source, alert boxes and plugins like Firebug. Today each browser has its own set of developer tools enabling a much richer debugging experience.

Browser developer tools can do much more than just explore the DOM. They can create files, audit pages, emulate devices, simulate network conditions, and much more. Jon gives a quick overview of a few of these features and shares some resources for learning more about the Chrome Developer Tools.

Jon demonstrates how to open and navigate through the Chrome Developer Tools. He gives a brief overview of each panel as well as the device emulator. Jon will be taking a deeper dive into each of the areas later in the course.

The Elements panel contains a direct representation of the DOM. Tags can be expanded, collapsed, and even edited. When an element is selected, any CSS styles are displayed in the Styles and Computed tabs. Jon shares a few tips and shortcuts for working with elements and styles while inspecting a page.

Jon demonstrates how to use DOM break points to jump to any JavaScript code that modifies a specific element or subtree. After that he looks at the different ways to work with color formats and the color picker. He also spends a few minutes talking about how code specificity is represented in the developer tools.

The Sources panel displays every source file loaded on the page and organizes them based on the domain where they originated. These files are editable and the changes are immediately reflected in the browser. In order to persist the changes, Jon demonstrates how to create a Workspace which maps the network resources to their corresponding files in a directory on your local computer.

In this challenge, you will use the Chrome Developer Tools to edit a page. You’d modify a number of styles, move around a few elements, and test the design on a mobile device layout. After assigning the challenge, Jon answers a few audience questions.

Jon walks through the solution to the first challenge. He also answers a number of questions from the audience.

Jon introduces the debugging tools located under the Sources panel. He explains how to set breakpoints, add watch variables, and explore code within the call stack. Jon then demonstrates stepping through code once a breakpoint is reached.

Most of the time, JavaScript errors will be located within the application source code and not inside any included libraries. Jon demonstrates how to “black-box” scripts so they are ignored by the browser developer tools. Then, in response to an audience question, Jon introduces the debugger api which allows you to use the debugger; JavaScript statement in your code to force the browser to break on a specific line.

In this challenge, you will use the various debugging techniques learned in this section to diagnose an issue in Jon’s GitHub repository search form.

Before moving on to the solution to the second challenge, Jon takes a step back and reviews the Scope area in the debugging window. He then answer a couple audience questions about some of the inconsistent behavior of the developer tools.

Jon walks through the solution to the second challenge.

Jon wraps up the debugging section by talking about conditional breakpoints and XHR breakpoints. Conditional breakpoints allow you to enter a boolean statement which will be tested before the breakpoints is executed. An XHR breakpoint will only execute a breakpoint when an XHR request contains a specified string of text.

The performance of a webpage can affect more than just the perceived load time. Poor performance can translate to a loss in traffic or even a decline in sales. Jon introduces the Audits panel and runs his first page audit. He explains the initial results and foreshadows some of the topics he’ll be getting into later in this section.

After answering a few audience questions, Jon talks through a few of the most common audit problems. These include combining external JS/CSS files, enabling GZIP, and compressing images.

The Network panel displays a lot of information about how the page loaded. There is a filterable waterfall diagram showing when and how long each asset took to load. Detailed information about each asset including size, type, and initiator is listed at the bottom. Jon also demonstrates how to take screenshots as a page is loaded to inspect the user’s experience at different points of the loading process.

The timeline in the Network panel displays loading information about each asset. This loading information is color-coded so it’s easy to identify what part(s) of the loading process take the most time and have the largest impact on performance. Jon spends a few minutes defining the terms associated with this loading process.

Jon talks through the most common network-related problems you will encounter when debugging the performance of a web application. This may include too many resources being retrieved by a single client, bad network conditions between the client and server, or a slowly responding server application. He also quickly demonstrates the network simulator which will simulate different network connection speeds.

Jon begins walking through the many parts of the Timeline panel. The Timeline panel is able to capture network performance, JavaScript profiling, screenshots, memory usage, and screen painting. You are able to turn on and off the different categories so only the applicable profiling information is displayed on screen.

Since JavaScript is single-threaded, it’s important to be able to identify the process running on the main thread of the application. Jon show how to navigate the main thread viewer in the Timeline panel and analyze the various call stacks being executed. Some processes, like parsing HTML, cannot be avoided or optimized. Others, like user-defined functions, may be running longer than they should and indicate a place for performance improvement.

In this challenge, you will spend some time profiling a webpage. You can run a page audit and record the page loading with the Timeline panel. Look through the profiling information to locate any places where the page could be optimized.

Jon begins walking through the solution to challenge 3. In this first part he uses the Audits panel to run a page audit. He then switches over to the Timeline panel to start investigating what’s running on the main thread.

Jon wraps up the solution to the third challenge by looking at some of the additional areas where the page could be optimized. One of the optimization tools he uses is ImageOptim for compressing images.

Under the Profile panel in the developer tools, Jon runs an individual profile test. This avoids the sometimes cluttered interface of the Timeline panel. After running the CPU profile test, he inspects one of the JavaScript files. The execution time is displayed for each function allowing easy identification of which functions are taking longer to execute.

Page jank is any stuttering or halting the user sees when a site or application isn’t keeping up with the refresh rate. Most devices refresh their screens 60 times per second. The goal is for the browser to match this refresh rate to keep the webpage or application looking smooth. Jon demonstrates how to find the Rendering panel and open the Frames Per Second Meter to monitor the page’s refresh rate. He also talks about using Paint Flashing to identify areas of the screen that are being repainted.

After answering a few audience questions, Jon talks about using the will-change CSS property to pass the rendering of DOM elements from the CPU to the GPU. While this is an effective way to increase the performance of the page, overuse of this property can have negative consequences.

In JavaScript, memory is freed up through a process called garbage collection. Objects that are no longer referenced are flagged and cleared by the garbage collector. A memory leak typically occurs when an object that should be garbage collected is not. Jon talks through a few of the most common places memory leaks occur in JavaScript.

The final challenge involves find memory leaks on a webpage. Before beginning the exercise, Jon talks quickly about using the Heap Snapshot feature in the Profile panel which allows you to compare the difference in memory from two different points in time in the application.

Jon walks through the solution to challenge 4.

Experiments are browser features that are turned off by default because they may not be completely implemented or stable. Jon demonstrates how to enable the Dev Tools experiment which adds a few additional testing tools to the existing browser developer tools. Jon then shares a few resources on where to find more information, tips, and tutorials for using the browser developer tools.

Jon wraps up the course by doing a performance audit on a few websites. The first site he selects is frontendmasters.com .

Jon walks through a performance audit on skill silo.com .

Jon walks through a performance audit on tauck.com .

Jon walks through a performance audit on buchbinderei.it .