Performance Flame Charts

The Performance Panel Is Your Time Machine

The Memory panel tells you what is in memory. The Performance panel tells you what happened over time — every function call, every style recalculation, every paint, every frame. It is the single most powerful debugging tool in the browser, and most engineers barely scratch the surface.

A performance recording captures everything the main thread did during a time window. The flame chart is the visualization — a stacked bar chart where width is time and height is call depth.

Recording a Performance Profile

1. Open Chrome DevTools → Performance tab
2. Click the Record button (circle icon) or press Ctrl+E / Cmd+E
3. Perform the interaction you want to analyze
4. Click Stop

For page load analysis, click the reload button (circular arrow) instead — it automatically starts recording, reloads the page, and stops when the page is loaded.

Anatomy of the Performance Panel

The recording shows several lanes from top to bottom:

1. Frames Lane (FPS)

A bar chart of frame rates. Green bars mean the browser achieved a smooth frame. Red or short bars mean dropped frames. Hover over any bar to see the exact frame duration.

2. CPU Chart

A color-coded area chart showing CPU activity:

A healthy profile shows lots of grey (idle). A sluggish profile is wall-to-wall yellow and purple.

3. Main Thread Flame Chart

This is where the real information lives. Every function call is a bar. Width is execution time. Bars are stacked — a bar on top was called by the bar below it.

Reading Flame Charts

The flame chart is read top to bottom (unlike traditional flame graphs which go bottom to top). The topmost bars are the entry points (event handlers, timers, requestAnimationFrame callbacks), and bars below them are the functions they called.

┌──────────────── onClick ────────────────┐
│  ┌──── processData ────┐ ┌─ updateUI ─┐│
│  │ ┌ parse ┐ ┌ sort ──┐│ │ ┌ render ┐ ││
│  │ └───────┘ └────────┘│ │ └────────┘ ││
│  └─────────────────────┘ └────────────┘│
└─────────────────────────────────────────┘

In this example:

• onClick is the entry point (widest bar — total time)
• It calls processData and updateUI
• processData calls parse and sort
• sort is wider than parse — it takes more time

Self Time vs Total Time

This distinction is crucial and trips up many engineers:

• Total time — how long the function was "on the stack," including time spent in functions it called
• Self time — how long the function spent doing its own work, excluding child calls

function parent() {
  doSmallWork();     // 5ms
  child();           // 200ms (the child is slow)
  doMoreSmallWork(); // 3ms
}

parent() has:

• Total time: ~208ms (entire execution including child)
• Self time: ~8ms (just doSmallWork + doMoreSmallWork)

If you are looking for optimization targets, sort by self time. A function with high total time but low self time is not the bottleneck — one of its children is.

The Three Analysis Views

Below the flame chart, DevTools offers three tabular views of the same data:

Bottom-Up View

Groups by function and sorts by self time. Start here. This immediately tells you which individual functions consumed the most CPU time, regardless of who called them.

Call Tree (Top-Down) View

Shows the call hierarchy from entry points down. Useful for understanding the path that led to expensive work. "Which user action triggers which expensive chain?"

Event Log

A chronological list of all events, function calls, and browser activities. Useful for finding the exact sequence of events and their timestamps.

Identifying Long Tasks

A long task is any task that blocks the main thread for more than 50ms. Long tasks are the primary cause of poor Interaction to Next Paint (INP) scores because user input cannot be processed while a long task is running.

In the flame chart, long tasks are marked with a red triangle in the top-right corner of the task bar. The red area shows how much of the task exceeds the 50ms threshold.

┌────────────── Long Task (120ms) ──────────────┐
│                                    ████████████│ ← red area (70ms over budget)
│ ┌── handleClick ──────────────────────────────┐│
│ │ ┌── processItems(5000) ─────────────────────┐│
│ │ │         (this is the bottleneck)          ││
│ │ └───────────────────────────────────────────┘│
│ └──────────────────────────────────────────────┘│
└─────────────────────────────────────────────────┘

Understanding Rendering Phases

When the browser needs to update the visual display, it goes through a pipeline. These phases appear in the flame chart as purple and green bars:

In the flame chart:

• Recalculate Style (purple) — triggered by CSS changes, class toggling
• Layout (purple) — triggered by geometry changes (width, height, position, adding/removing elements)
• Paint (green) — triggered by visual changes (color, background, shadow)
• Composite Layers (green) — always happens, usually very fast

If you see Layout bars that are unexpectedly wide, you likely have layout thrashing (reading layout properties after writing style changes in a loop).

User Timing Marks

You can add your own markers to the flame chart using the User Timing API:

performance.mark('data-fetch-start');

const data = await fetch('/api/items');

performance.mark('data-fetch-end');
performance.measure('Data Fetch', 'data-fetch-start', 'data-fetch-end');

performance.mark('render-start');
renderItems(data);
performance.mark('render-end');
performance.measure('Render Items', 'render-start', 'render-end');

These marks appear as vertical lines in the Timings lane of the Performance panel. Measures appear as labeled bars. This makes it easy to correlate your application logic with what you see in the flame chart.