Read a performance recording

A performance recording is a timeline of evidence. Start with a narrow question such as “why did this click take 400 ms to update the page?” A recording of several unrelated minutes makes that answer harder to find.

Capture a short window around the load or interaction, then read from the visible symptom toward its cause:

1. Use screenshots and frame markers to locate when the page visibly changed.
2. Use interaction and Web Vitals markers to locate the relevant event.
3. Inspect the Main track for tasks between input and paint.
4. Expand wide entries to find JavaScript, style, layout, or paint work.
5. Follow Network requests and initiators when the main thread is waiting for bytes.

In the flame chart, width represents duration and vertical stacking represents calls. A wide parent may be expensive because of its children, so distinguish total time from self time. Bottom-up views help group the functions that accumulated the most time; call-tree views preserve how execution reached them.

Look for patterns, not just one red marker:

• one long task delaying an interaction
• repeated layout events caused by alternating DOM reads and writes
• a large paint after a small visual change
• an idle gap ending when a late network request completes
• script evaluation occupying the loading path

Apply CPU or network throttling only when it represents the affected visitors, and record the setting with your result. Throttling is a model, not a perfect copy of a physical device.

Before changing code, write one sentence that links evidence to cause: “The click waited behind a 280 ms task created by renderResults().” After the fix, reproduce the same action and show that this specific interval changed.