How to Use Chrome DevTools for Performance Audits

JavaScript samples, waterfall charts, network throttling, local environments—the truth is Chrome DevTools’ Performance tab can be tricky to navigate, especially for non-technical people. 

That’s why many website owners default to using more user-friendly page speed testing tools like Google’s PageSpeed Insights and GTmetrix.

However, just because you don’t have 15 years of dev experience, it doesn’t mean you cannot leverage Chrome DevTools’ capabilities.

All you have to do is familiarize yourself with the terms and learn how to use the various features.

In the following lines, we will explain how to get the most out of Chrome DevTools so you can gain valuable insights into your website’s performance.

Read on! 
 

Chrome DevTools vs PageSpeed Insights vs GTmetrix

Before we dive into the nitty-gritty of the Performance panel, we want to make sure you understand the advantages of Chrome DevTools and how it compares to tools like PSI and GTmetrix:
 

PageSpeed Insights

Google’s PageSpeed Insights is a tool that measures both lab data (collected in a controlled environment to gauge potential performance issues) and field data (based on real user experiences from the Chrome User Experience Report, or CrUX). 

A key advantage of PageSpeed Insights is its use of field data to reflect real-world performance, evaluating the Core Web Vitals and making it useful for understanding actual user experiences. 

Additionally, after evaluating the page, PSI assigns scores and provides suggestions to improve areas like image compression, resource caching, and JavaScript execution. This allows site owners and developers to easily pinpoint improvements. 

However, PSI has limitations. Field data only appears if a page has enough visitors in the CrUX database, so smaller sites may lack these insights. Also, lab data doesn’t fully replicate the diverse conditions users may face, such as different devices or network speeds, which can limit the accuracy of PSI’s suggestions. Moreover, there isn’t an option to customize your test conditions to replicate potential issues real users may face. 
 

GTmetrix

GTmetrix is another widely popular web performance tool that provides insights into a website’s speed, structure, and load behavior, helping users optimize their sites for better performance. Using metrics from both Lighthouse and Web Vitals, GTmetrix assesses page elements like Largest Contentful Paint (LCP), Total Blocking Time (TBT), and Cumulative Layout Shift (CLS), each of which impacts load speed and user experience. 

GTmetrix scores a page based on these metrics and provides a report with actionable suggestions, from compressing images and reducing JavaScript load times to optimizing server response times.

As useful as this tool is, GTmetrix’s primary limitation is its reliance on lab data, which, while helpful for consistent testing, may not fully capture real user experiences under diverse conditions. Also, some advanced features, like mobile device testing and certain performance metrics, are available only in the paid plans.
 

Chrome DevTools

It’s true that Chrome DevTools is more complex than the other popular tools. But at the same time, you can:

1. Work with live, real-time data

Most page speed tools (like PSI) give you a static report showing how your site performed at one moment in time. The Performance tab in DevTools, on the other hand, lets you understand how your website responds in real-time as you interact with it—like when you scroll, click buttons, or navigate pages. This gives a more accurate sense of what real users experience as they browse your site.

2. Analyze your Core Web Vitals immediately

Core Web Vitals are key metrics Google uses to judge your site's performance, like how quickly your site loads (LCP), how stable your page layout is (CLS), and how fast it responds to user interactions (INP). While many tools only give you these metrics after a test is run, Chrome DevTools shows them to you live as you’re interacting with the site. This helps you quickly spot any issues that might hurt the user experience. 

3. Customize your test conditions

DevTools allows you to simulate how your site would load on different devices (like phones) or under slower internet conditions. This is useful for testing how your site performs for users with slower internet speeds or older devices.

All of these make the Performance panel an invaluable tool. And you can get the most out of it by simply understanding how to navigate it…
 

How to Use Chrome DevTools’ Performance Tab

To access the Performance tab:

1. Open Chrome DevTools:
   • Right-click on any part of the webpage and select "Inspect" from the menu.
   • Alternatively, use the keyboard shortcut:
     • Windows/Linux: Ctrl + Shift + I
     • Mac: Cmd + Option + I
2. Navigate to the Performance Tab:
   • In the top menu of DevTools, click on the "Performance" tab. If it's not visible, click the ">>" icon to find it under additional tabs.

Once inside, here are the steps you need to take to perform a comprehensive audit:
 

Step 1: Monitor Your Core Web Vitals Live

Introduced in Chrome 129, Chrome DevTools now shows your local Core Web Vitals metrics. The best part is that there’s no need to start a recording; the metrics are gathered in the background and available whenever you need them. 

In other words, whenever you feel your website’s slow, you can simply access the Performance panel and understand why. 

 

But what does local Core Web Vitals mean, and how can this live view section help you? 

The local Core Web Vitals results represent the performance metrics collected from your local browsing session, taking into account your machine and network conditions. 

Furthermore, as you load and interact with the page, the metrics—Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint—will update in real-time. Also, all metrics are color-coded based on their performance thresholds, making it easy to identify any issues as they occur.

When it comes to INP, you will see different results as you interact with different page elements. The good news is that right under the metrics, you will see the elements that triggered INP so that you can pinpoint the culprit.

 

Compare your local experience to the experience of your visitors

As you may know, the biggest issue of focusing entirely on your PageSpeed Insights’ Performance score is that it’s based on lab data. Well, your local results, in a sense, are also based on tests run in perfect conditions. 

 

And while these tests are great for debugging, they do not show what truly matters—how you real-world visitors experience your site. 

The Performance panel lets you compare your local results to your real-user (field) data. 

 

To start seeing field data, click “Set Up” in the Field data widget and then “Ok” in the configuration window.

If your site/page meets the eligibility criteria, your field data will immediately appear. 

But why is it important to enable this comparison? 

As you can see from our example above, all of our Core Web Vitals were in the “good” threshold, implying that the website provides an excellent user experience. If we stop there and rely entirely on the information from our local metrics, everything seems to be good, and we do not need to apply any optimizations.

However, once we enabled the field data, we saw that the reality was a bit different. For instance, while our LCP element was loading in 678ms in our local environment, for 75 percent of the real-world visits, it took 2.69s. This falls under the “needs improvement” threshold. Same with INP. 

So, how can you set your local environment to allow you to identify potential issues?

 

How to set up your environment to reproduce issues

There are lots of moving parts that shape one’s experience on a web page. However, the Performance panel allows you to configure your environment to some extent, to be similar to how real users perceive your site.

When the field data is enabled and available, the Recording settings section will suggest emulating the most common device type real visitors use. 

The widget allows you to specify device type and throttle your CPU and network connection. 

These are all great ways to make your local device perform more like a real user, thus bringing issues to the surface that you might have missed otherwise. 

Provide your visitors with a fast and seamless experience. Pass your Core Web Vitals automatically with NitroPack →

Step 2: Capture a Performance Report

Aside from the latest Core Web Vitals live feature, the Performance panel has always enabled users to capture a performance recording. You can either:

1. Record Load Performance

This option is designed to help you analyze the performance of your webpage during the initial load phase. It captures data from the moment the page starts loading until it has fully rendered, including:

• Network Requests: Time taken for each resource (images, scripts, stylesheets) to download.
• Parsing and Compiling: HTML parsing, CSS calculation, and JavaScript compilation.
• Rendering and Painting: Initial rendering processes, including layout and paint events.
• Load Events: Metrics like First Contentful Paint (FCP), Largest Contentful Paint (LCP), and Time to Interactive (TTI).

 

2. Record Runtime Performance

This option, on the other hand, helps you analyze how your webpage performs after it has loaded, focusing on user interactions and dynamic content updates, but also: 

• JavaScript Execution: Function calls, event handlers, and scripts running during interactions.
• Rendering and Layout: Recalculations of styles, layout shifts, and paint events triggered by user actions.
• User Interactions: Response times for clicks, scrolls, input events, and animations.
• Performance Metrics: Issues like long tasks, frame drops, and jank that affect smoothness.

As powerful as both options are on their own, you can get even more insights by customizing the capture settings:

• Disable JavaScript samples: Turns off the tracking of detailed JavaScript processes, making performance tests faster but with less detailed information about how JavaScript is running.
• Enable advanced paint instrumentation (slow): Provides detailed insights into how the browser draws your web page, but it can make the recording process slower because it's collecting extra information.
• Enable CSS selector stats (slow): Gathers detailed information on how your site’s styles affect its performance, but it can slow things down as it’s running these checks.
• CPU: Simulates different levels of CPU throttling to mimic slower devices, allowing you to test how well your site performs on lower-powered machines.
• Network: Simulates various network speeds (e.g., 4G, 3G) to test your site's performance under different internet connection conditions.
• Hardware concurrency: Sets the number of processor threads available to simulate different levels of hardware power (e.g., testing on devices with fewer CPU cores).

 

Step 3: Analyze Your Performance Report

The power of Chrome DevTools’ Performance panel lies in the comprehensive reports it builds. 

There’s no one better at explaining how to navigate the recording report than the Chrome team itself, so if you want to dig deeper, we recommend reading this article.

In the following lines, we’ll briefly overview the different sections and what insights you can gather using them.

Once your recording is complete, the first thing in the report is the Timeline. 

The Timeline offers a visual overview of everything that happens on your webpage during a performance recording. It tracks the stages of your site’s load process, including rendering, scripting, and user interactions. You can quickly spot areas where performance issues arise, such as resource-loading delays or long tasks that block interactivity. 

You can select a portion of the recording to analyze it better. For instance, if we want to see why it took canva.com 2000ms to load any content, we can zoom in on the Timeline and see that the browser was processing some render-blocking CSS files.

Next, the Performance panel represents the main thread activity in a Flame Chart.

The Flame Chart breaks down how JavaScript tasks are handled by the CPU, highlighting how much time each task takes. You can use this chart to pinpoint long tasks—those that block user interaction and make the page feel sluggish. By hovering over different blocks, you can see which functions are the most resource-heavy. 

Clicking on each task, you can see additional info in the Summary tab.

The Summary gives a high-level breakdown of how your page is using resources. It shows you the time spent on scripting, rendering, and loading. The Summary is a great starting point for identifying which area (e.g., JavaScript execution or painting) is consuming the most time, offering a quick overview of the main performance drivers.

Speaking of summary, let’s take a look at the other three tabs—Bottom-Up, Call Tree, and Event Log.

1. Bottom-Up: In this view, you’ll see how time is distributed across different functions, starting from the bottom of the call stack. It helps spot specific tasks or functions that take longer to execute and might be causing slowdowns. This view helps you focus on fixing the most time-consuming code.

2. Call Tree: Presents a top-down view of your function calls, showing how much time each function and its child functions take. It helps you track the overall flow of your program and drill down into specific functions that are causing performance issues.

3. Event Log: Provides a detailed list of events, such as network requests and user interactions, that occurred during the recording. Each event is timestamped, so you can see exactly when and where issues arise. This is particularly useful for debugging interactions or events that might be slowing down your site at specific points in time.

It’s safe to say that by combining all these different views in Chrome DevTools, you can understand how your site performs and identify the areas that need optimization.
 

Doing Your First Performance Audit (Checklist)

We know that reading about something isn’t as actually doing it.

So, to ensure you leave this article with some actionable steps you can apply immediately, we gathered the most critical points and turned them into a checklist. 

Here’s what you need to do next time you use Chrome DevTools’ Performance tab:

• Configure field data so you can compare your visitors’ experience to your local results
• Fine-tune your local environment to emulate the experience of your users by throttling your CPU and network
• Hover over the three Core Web Vitals to get extra information on what the actual culprit is
• Make sure to record both your site’s initial load and runtime performance
• In the recording report, zoom in on the Timeline to identify possible render-blocking resources that are slowing down your load times
• Leverage the Flame Chart to pinpoint long tasks that are negatively affecting your page’s responsiveness
   

FAQs

What is performance in DevTools?

In Chrome DevTools, performance refers to the set of tools and metrics that help analyze how well your website or web application loads and runs. The Performance Tab tracks aspects like page load times, JavaScript execution, rendering, and user interactions. It provides detailed insights into resource usage, highlighting any bottlenecks that might affect the speed and responsiveness of your site.
 

How do I throttle my CPU in Chrome DevTools?

To throttle your CPU in Chrome DevTools:

1. Open DevTools and go to the Performance Tab.
2. Click the gear icon (settings) at the top right.
3. In the "CPU" section, select a throttling level (e.g., 4x or 6x slowdown) to simulate slower devices
    

How to check page load performance in Chrome?

To check page load performance in Chrome, open DevTools and navigate to the Performance Tab. Once there, click the Record button and reload the webpage. As the page loads, the tool captures a detailed breakdown of resource loading, network activity, and CPU usage. After stopping the recording, you can view insights on how long different tasks took, including the time spent on loading scripts, rendering, and interacting with the page.