DevTools Performance panel: how to record and read it

What the panel is for

Lighthouse and PageSpeed Insights give you scores and a list of findings. They do not show you the sequence of events. The Performance panel records a trace: a detailed log of what the browser did, drawn on a timeline. You use it to answer questions such as:

• What was the browser doing between the first paint and the moment the page responded?
• Which script produced the long task that Lighthouse reports?
• Why did that tap take 400 milliseconds to show a result?
• Which request was holding up the main image?

The documentation we used for this guide dates from 2023. DevTools changes often, so a button or a label may have moved or been renamed. The ideas below stay the same.

Before you record

1. Use a clean window. A private window with extensions turned off avoids other people's code in your recording. Chrome extensions can add work to the page and change what you see.
2. Slow the processor and the network. Open the capture settings in the panel and choose a CPU slowdown and a network speed. The documentation notes that throttling is relative to your own computer: the "2x slowdown" setting makes your CPU work two times slower than usual. It also notes that DevTools cannot truly simulate a phone's processor, because the architecture is very different. Use the setting as a rough stand-in, and confirm important findings on a real phone. See testing on real devices.
3. Turn on screenshots if you want to see how the page looked at each moment.
4. Know what you are measuring. A recording is one run on one machine. Record several times, and compare.

Two kinds of recording

A load recording. Click Start profiling and reload page. DevTools first goes to a blank page to clear anything left from before. It then records while the page reloads and stops by itself a couple of seconds after loading finishes. Use this for questions about loading, such as why the main image is late.

A runtime recording. Click Record, use the page, then click Stop. DevTools records all activity that results from what you do. Use this for questions about responsiveness, such as a slow menu or filter.

How to read the recording

The panel shows an overview at the top and several tracks below it. Drag across the overview to zoom in on a part of the recording. The W, A, S and D keys also zoom and move when a track has the focus.

The Timings track

The Timings track shows markers for the events that matter for loading: First Paint, First Contentful Paint, Largest Contentful Paint, DOMContentLoaded and the load event, plus any marks you add with performance.mark(). Select one to see details in the Summary tab. A Largest Contentful Paint marker that comes late is where to start looking. Then work backward.

The Network track

Expand Network to see a waterfall of the requests during the recording. They are colored by type: HTML blue, CSS purple, JavaScript yellow and images green. A darker square on a request means a higher priority, and the Summary tab shows its initial and final priority. If those differ, the browser changed the priority during the recording, which matters for the main image. See resource hints and lazy loading.

Each request is drawn as a line, a bar and another line. The left line is everything before the request was sent, such as the connection. The light part of the bar is the request and the wait for the first byte. The dark part is the download. The right line is time spent waiting for the main thread. For the full request detail, use the Network panel. See the Network panel guide.

The Main track

The Main track shows what the main thread did, as a flame chart. The horizontal axis is time. The vertical axis is the call stack, so events above cause the events below them. A wider bar took longer. DevTools colors scripting activity yellow and rendering activity purple.

Long tasks. A task longer than 50 milliseconds gets a red triangle, and the part beyond 50 milliseconds is shaded red. A task of 140 milliseconds, for example, has its last 90 milliseconds shaded. This is how you find the long tasks that raise Total Blocking Time. See breaking up long tasks.

Click any event to see its details in the Summary tab. For a function, the tab shows where it was called from, and a link opens the file at the right line. If your source maps are available, DevTools finds your original files.

The Interactions track

The Interactions track shows taps, clicks and key presses. For an interaction longer than 200 milliseconds, the Summary tab shows a warning about Interaction to Next Paint, and the part above 200 milliseconds is shaded red. Use it to record a slow interaction and see which task ran underneath. See Interaction to Next Paint.

The tables below

There are three tabular views of the same activity, each answering a different question:

"Self time" is the time spent directly in an activity. "Total time" includes its children. Select part of the recording first, because the tables only show the selected portion. With nothing selected, the Summary tab breaks the time into loading, scripting, rendering and painting, which tells you which kind of work dominates.

Four questions, four routes

Why is the main image late? Do a load recording. Find the Largest Contentful Paint marker, then find the image in the Network track. Check when its request started and whether it had a high priority. If the request starts late, something earlier blocked it: a script, a stylesheet, or the image being found only after a script ran. See how to fix a slow LCP.

What is the long task? Find the red-triangle task in the Main track. Open it and follow the stack down to the widest events. The Bottom-Up tab names the functions, and each links to a file. A third-party file means the work is not yours to change. See third-party scripts.

Why is a tap slow? Record the tap. In the Interactions track, select the interaction. Look at the work under it: your handler, then style and layout, then painting. If the layout step is long, the page structure may be too large. See DOM size.

Is something forcing layout? A red triangle on a purple Layout event, with a warning about a forced reflow in the Summary tab, means a script changed styles and then asked for a measurement. The tab links to the line that caused it. The fix is to read all values first and make the changes afterward. DevTools' own tutorial uses exactly this example.

What newer versions of the panel add

The Chrome team's Web Vitals extension README describes features that moved into the Performance panel in Chrome 132, which became stable in January 2025. The extension has since reached the end of its life, and the team points users to the panel. When you open the Performance panel, the view starts with a live look at your local Core Web Vitals. From the README:

• Local and field values side by side. A configuration flow can show field data from the Chrome UX Report, at URL and origin level, next to your local numbers, for desktop and mobile.
• The LCP element and its phases. The panel names the element behind Largest Contentful Paint and splits the time into four phases: first byte, load delay, load duration and render delay.
• An interaction log. Every interaction that counts toward Interaction to Next Paint is listed, and expanding one shows its input delay, processing duration and presentation delay.
• A layout shift log. Shifts that occur together are grouped into clusters with a score, and the worst cluster is linked from the layout shift number.
• Insights in the trace view, such as the breakdown of Largest Contentful Paint by phase, and a marker for First Contentful Paint.

Names and positions may differ in the version you have, so check the current documentation. The recording method described above still applies.

Share a recording

Right-click the panel and choose Save Profile to save the trace as a file. A developer can open it with Load Profile and see exactly what you saw. This is often better than a screenshot or a score.

Limits and mistakes

• It is your machine. Your visitors' phones are slower. Throttle, and then confirm on a real device.
• The panel adds overhead, especially JavaScript sampling. You can turn the detailed call stacks off in the capture settings to see only the high-level events.
• One recording is not a result. Record several times and look for the pattern.
• Local is not live. A development build behaves differently from the version your visitors get. Record the live site when you can.
• A red triangle is a hint. It marks a place to look. It does not prove a fault.

Check your own page

Run the free audit to find what is slow, for example a long task or a late Largest Contentful Paint. Then record that page in DevTools with the CPU slowed down, and follow the route above that matches the finding.

Sources

• Web Vitals extension README: the features that moved into the Performance panel in Chrome 132.
• Performance features reference and Get started with analyzing runtime performance in the Chrome DevTools documentation: recording, throttling, the tracks, long tasks, interactions, the tables and the forced layout example.