DevTools flame strip and the frame lifecycle

You open DevTools Performance, record a scroll, and see a sea of coloured bars. Some bars are red. Most are yellow. You know jank is somewhere in there — but you don’t know which bar to fix. The flame strip is a map. This lesson teaches you to read it.

Reading the DevTools Performance flame strip

Open DevTools → Performance, click record, do whatever caused the jank, stop recording.

Track colours (Main thread):

• Yellow — scripting (JavaScript executing)
• Purple — rendering (style recalc + layout)
• Green — paint
• Dark blue — compositing

Track colours (Frames):

• Green — on-time frame
• Yellow — late frame
• Red — dropped frame

The flame strip stacks calls top-down: the top bar is what JS triggered; each bar below is what that called. Find a long bar in red or yellow — that is your bottleneck. Hover to see exact ms.

The frame lifecycle: exact order

Inside one frame the browser runs work in a strict order defined by the HTML spec:

1. Collect input events (mousemove, keypress)
2. Run setTimeout / setInterval callbacks if their time has elapsed
3. Run microtasks (promise resolutions) until the queue is empty
4. Run requestAnimationFrame callbacks
5. Run ResizeObserver and IntersectionObserver callbacks
6. Compute style and layout
7. Paint
8. Composite

After step 8 the browser yields to the OS and waits for the next vsync.

Crucial property: rAF runs before style/layout, so a write inside rAF is followed by exactly one layout pass for the frame — that is the entire purpose of rAF. ResizeObserver fires after layout but before paint; you can react to layout changes without triggering another forced layout. IntersectionObserver fires asynchronously across frames, never blocking the current one.

Microtasks vs tasks: scheduling boundaries

The microtask queue (promises, queueMicrotask) drains to empty between every step of the event loop, including between rAF callbacks.

A misbehaving promise chain that schedules itself indefinitely starves rendering — the browser cannot reach step 6 until the queue empties. This is why long promise chains and tight await loops appear in DevTools as a single uninterrupted yellow scripting bar, not a series of small ones.

Modern code that wants to yield to the renderer mid-task uses:

• scheduler.yield() (Scheduler API, Chrome 115+) — designed specifically for this
• setTimeout(fn, 0) — drops work onto the macrotask queue and unblocks rendering

Reactive frameworks and the pipeline

When React re-renders, DOM updates happen on the main thread, then the pipeline runs style and layout on changed nodes. Reconciliation itself is pure JS — it shows up as yellow in DevTools. If your re-render touches a node near the top of the tree, style invalidation cascades down the tree; if it touches an isolated leaf, the invalidation is local.

Key practice: keep state local, as close to the leaf as possible. A useState in a leaf component invalidates one node; a useContext on a top-level provider can invalidate hundreds. The same principle applies to Svelte stores, MobX observables, Vue refs — every reactivity model eventually writes to the DOM, and a DOM write triggers the same pipeline.