Profiling with Chrome DevTools

Recording a performance trace, reading the flame chart, and hunting down long tasks that block interaction.

RUM finds the slow segment; WebPageTest shows the symptoms. To find the line of code at fault, you record a trace in the Chrome DevTools Performance panel. It looks intimidating, but it's really just a few linked views — and once you can read the flame graph, you can catch the classic killer: a forced reflow.

Don't be scared by the wall of color. The Performance panel is a stack of time-aligned tracks — scroll/zoom one and they all move together:

• Summary — where the time went: scripting, rendering, painting, idle.
• CPU / Frames — frame rate over time; red means dropped frames.
• Interactions — each click/tap split into input delay, processing, presentation (your INP breakdown).
• Main thread — the flame graph: every task and its call stack. The most useful track by far.

The flame graph reads top-down: a task at the top calls functions below it, each bar a call in the stack. Wider = longer. A task over 50 ms gets flagged as a long task (the red corner). Click into the stack to find who's eating the time — and hover any frame to see whether it's scripting or rendering:

That “Layout (Forced)” entry is the most common surprise in real traces — layout thrashing. It happens when you write a style and then immediately read a layout property (like offsetTop, offsetHeight, getBoundingClientRect()) in the same loop. The read can't be answered until layout is up to date, so the browser is forced to re-run layout synchronously — once per iteration. Toggle the fix:

for (const img of images) {
  img.style.top = top + "px";   // WRITE
  top = img.offsetTop + 3;       // READ → forced synchronous layout!
}

Two ways to record

Record (then interact, then stop) captures a specific interaction — perfect for debugging a janky scroll or click. Start profiling and reload captures the whole page load from the first byte, and adds a Timings track with DCL, FP, FCP, and LCP marked.

Reproduce your users' conditions

Before recording, set CPU throttling (4×/6× slower to mimic a cheap phone) and network throttling (Slow 3G). A bug that's invisible on your M-series laptop is glaring at 6× CPU — which is exactly what your real users feel. This is how you turn the RUM finding (“mobile users in India are slow”) into a reproducible trace.