Web development

DevTools Performance, panel by panel: what to read in a trace

Five seconds of recording, three lanes to read and an exported trace you can count with node: what to look at in the Performance panel.

Key points

  • Record with CPU 4x slowdown and the cache disabled, then read three lanes only: Frames, Main and Network.
  • A red triangle in the Main lane is a long task over 50 ms: that is where LCP loses time, not in the image.
  • An exported trace is JSON with `traceEvents` and `RunTask` in microseconds: one `node` command turns it into a reportable number.

Short answer: record five seconds in the Performance panel, then read the trace in three places: the Frames lane, the Main lane and the Network lane. The rest of the panel is detail, and only matters once you found the problem.

Two settings to set first

In the top bar pick CPU 4x slowdown and Network Fast 4G: a fast laptop hides the problems a phone shows. Keep the option that disables the cache on, otherwise the second recording measures the cache rather than the page.

The three lanes that matter

  • Frames: the frames drawn and the ones dropped; a red block is a frame longer than 16 ms.
  • Main: JavaScript tasks in chronological order; red triangles are long tasks over 50 ms.
  • Network: request order and duration; this is where you see an LCP waiting on an image.

Counting long tasks instead of guessing

# esporta il trace dal pannello (Export trace) e conta i long task
node -e "const t=require('./trace.json');const e=t.traceEvents||t;const tasks=e.filter(x=>x.name==='RunTask'&&x.dur>50000);console.log(tasks.length,'long task; max',Math.max(...tasks.map(x=>Math.round(x.dur/1000))),'ms')"

An exported trace is JSON: traceEvents holds the events, RunTask the main-thread tasks, dur the duration in microseconds. The count matches what the panel shows, but it becomes a number you can put in a report.

The metrics inside the trace

The Timings lane marks LCP, INP and CLS on the same timeline. When LCP lands at 2.9 s and the Main lane shows a 400 ms long task just before it, the cause is JavaScript and not the image: that is where measurement turns into diagnosis.

A named limitation

A trace recorded on your laptop does not tell you what users see: it is lab data, with simulated network and CPU. A long task missing locally can appear on a three-year-old phone, so the final call belongs to field data.

Where to continue

The catalogue holds the gauge component, the metric card and the chart category blocks. For the rest read the Lighthouse CI thresholds, the PerformanceObserver guide and the React profiler.

Frequently asked questions

How long should a recording be?

As long as the action you want to measure, plus a second before and after. Five seconds covers a page load; for an interaction, record just the click and the update that follows.

What is the difference between a long task and a dropped frame?

A long task is a main-thread block over 50 ms, a dropped frame is a frame that misses its 16 ms budget. The first causes the second, but a different lane shows each one.

Can I read a trace without Chrome?

Yes, once you exported it: the file is JSON and holds the same events as the panel. A node command filters RunTask and computes duration and count, which helps compare two builds.

Why do the numbers change on every recording?

Because a trace measures one run, with simulated yet non-deterministic network and CPU. Record five times and read the median: a single value is not a measurement.

Does the Performance panel replace Lighthouse?

No. Lighthouse gives a score against fixed rules, the panel gives the cause of a delay on one page. You need both: one for the budget, the other to understand why.