Reading a performance profile

The color language

Before anything else: in both the CPU overview and the flame chart, color encodes the kind of work, not the file. Learn these five and half the panel reads itself.

A wall of one color is a diagnosis in itself. A mostly-yellow profile is CPU-bound on JavaScript, exactly the shape of the sample trace used throughout this guide.

Anatomy of a network request

In the Network track, each request is one bar. Its shape tells you where the time went. Click a segment to inspect it, then switch the scenario to see how the same bar reshapes when the bottleneck changes.

The waterfall tells a dependency story

The vertical shape is the real signal. Bars that start at the same X were discovered together; a staircase means each request had to wait for the previous one. Toggle the two patterns.

The flame chart, decoded

Two axes trip everyone up at first. X is real time. Y is call-stack depth: each row is a function called by the row above it. Width is total time including children. Click any frame to read it.

Self vs total is the concept that separates novice from expert: a fat bar with a fat child has almost no self time, the child is the culprit, not the parent. Toggle Show self time above to see each frame’s own work hatched.

Initiators: reading the arrows

Select an event and DevTools draws arrows to what scheduled it and what it schedules next. A setInterval re-arms itself, so its firings chain across the timeline. Click a firing.

Show initiator arrows

In real DevTools

One dataset, three views

The Flame chart, Call tree and Bottom-up are the same samples, aggregated differently. This is the exact tree from the flame chart above; switch the lens and watch what each one surfaces.

The punchline: the flame chart's widest bars (Task, Evaluate Script) are mostly their children. Bottom-up, sorted by self time, exposes the real hogs, detectChanges and process, buried deep and invisible from the top. That gap is why experts open Bottom-up first.

The master diagnosis: CPU-bound or network-bound?

Line the network track up against the main thread. If the thread is idle waiting on a bar, you have a network problem. If it’s solid with work while nothing downloads, it’s a CPU problem. Flip between the two.

LCP & the four phases

The trio's loading metric. LCP (Largest Contentful Paint) marks when the biggest element in the viewport, usually the hero image or headline, finishes painting. The panel splits it into four phases; read which one dominates and you know whether the fix is on the network or the main thread.

The whole diagnosis is one question: did the resource arrive late (load delay + load time) or did the render arrive late (render delay)? Thresholds: good ≤ 2.5 s, needs work ≤ 4 s, poor > 4 s. In the panel, the LCP marker sits in the Timings track; hover it to highlight the element. You don’t estimate these sub-parts by hand: open the Insights sidebar and the LCP by phase insight breaks the metric into exactly these four sub-parts, while LCP request discovery flags a resource the browser found too late.

Frames & layout shifts (CLS)

Two more overview tracks carry the visual-stability story. Frames shows every painted frame: uniform green is smooth, a fat block is a stalled thread. Layout Shifts marks content jumping, the raw material of CLS.

CLS = impact fraction × distance fraction, summed within a session window. The cure is boring: reserve the space (width/height, aspect-ratio) so late content lands without pushing anything.

INP & interactions

Loading metrics are only half the story. INP (Interaction to Next Paint) measures responsiveness, from a tap to the next painted frame. It splits into three phases; read each and you know exactly which one to fix.

Thresholds: good ≤ 200 ms, needs work ≤ 500 ms, poor > 500 ms. In the panel, open the Interactions track to see each interaction's three phases, then attribute the processing block to a handler in Bottom-up. Scroll jank is the same story: long tasks stealing the frame budget while you scroll. When there is no real interaction to measure, Total Blocking Time stands in for INP in the lab: the blocking part of every task past 50 ms, summed. Drive TBT down and INP usually follows.

Animations & compositing

The Animations track (purple) lists every property a CSS transition or @keyframes animates. One question decides whether it is cheap: is it composited? Composited animations run on the compositor, off the main thread, and stay smooth even under load. Everything else recomputes layout or paint every frame, and DevTools marks it Compositing failed.

Composited-safe: transform, opacity, and filter. Animating anything that changes box size or pixels (width, margin, top/left, box-shadow, color) forces the main thread to work each frame. Select an animation in the panel and read the Compositing failed reason in Summary; the fix is almost always to move it to transform/opacity.

Recalculate Style, Layout & the render pipeline

Whenever styles change, the browser runs a fixed pipeline before the screen updates: Recalculate Style → Layout → Paint → Composite. On Main each stage is its own event; reading them tells you what changed, how much it cost, and whether it stole the frame. Click a stage, and switch what triggered it.

The event's Initiated by tells you where the recalc came from, here a Parse stylesheet (guide.css) finishing and invalidating the page. Read Elements affected on Recalculate Style, and Nodes that need layout / Layout root on Layout: a root of #document with hundreds of nodes is a page-wide reflow. When Recalc + Layout run long they turn the Task into a long task that blocks the main thread, so a tap landing on it waits, and that delay lands in INP.

The expert reading workflow

Nobody eyeballs the flame chart cold. This is the order the pros actually work in.

Reading function-name signatures

Speed comes from recognizing code by its frame names, then attributing it by URL in Bottom-up. Filter by where the code lives; a few you will meet constantly:

Don’t recognize a stack? Group Bottom-up by URL to see the owner (1st vs 3rd party), or right-click a frame and Add script to ignore list to collapse code you don’t own. The frame name plus its owner is the whole diagnosis.

Reading request signatures

Frame names identify code in the flame chart; request origins identify it in the waterfall. Recognize the vendor by domain, then judge it by where the request sits: on the critical path, render-blocking, or a spare connection you can safely defer. Filter by what the request does:

In the Network panel, add the Domain column (right-click the header) or the 3rd-party filter to group these in one pass; in the Performance panel, hover a network bar to read its URL. Origin plus purpose is the whole attribution.