Read a performance recording

A performance recording is a timeline of evidence. The first time you open one it looks like noise. The trick is to arrive with a narrow question. “Why did this click take 400 milliseconds to update the page?” is a good question. “Why is the page slow?” is not.

Record a short window around the load or the interaction.

Read from symptom to cause

Start from what the user saw and work backwards:

1. Use the screenshots strip and the Frames track to find when the page visibly changed.
2. Use the Interactions and Timings tracks to find the event you care about.
3. Look at the Main track between the input and the paint. That’s where the time went.
4. Expand the wide blocks. Yellow is JavaScript, purple is style and layout, green is paint.
5. When the Main track is idle and the page is still waiting, follow the Network track.

How to read the flame chart

The Main track is a flame chart. Width is duration. Vertical stacking is the call stack: a function on top called the functions below it.

A wide parent isn’t always the culprit. It may be wide because its children are. DevTools separates total time, the function plus everything it called, from self time, its own work. Look at self time to find where the CPU was busy.

The Bottom-Up tab groups functions by accumulated time. The Call Tree tab keeps the call order. I use Bottom-Up to find the expensive function and Call Tree to see how we got there.

Patterns to look for

Don’t stop at the first red marker. Look for a shape:

• one long task between an input and its paint
• many small Layout blocks in a row, the signature of alternating DOM reads and writes
• a big Paint block after a small visual change
• an idle gap on the Main track that ends when a late request completes
• script evaluation hogging the loading path

Each shape points to an earlier lesson in this course.

A note on throttling

CPU and network throttling make the recording resemble a slower device. Use them when they represent your real visitors, and write the setting next to your result. A “4x slowdown” trace and an unthrottled trace are not comparable.

Write the sentence

Before you change any code, write one sentence that connects evidence to cause. “The click waited behind a 280 ms task created by renderResults().”

If you can’t write it, you haven’t finished reading the recording. If you can, you know what to measure after the fix: the same click, and this interval getting shorter.