The three-track method: reading traces and building a monitored system

A junior engineer optimises the “Add to cart” handler — it already takes 12 ms, well under budget. INP stays at 480 ms. A second engineer finds a 900 ms hydration long task that starts before every early tap. Fixing the handler optimised something that was not the constraint. The constraint was the task the tap was queuing behind. Reading a trace is not knowing that things are slow — it is knowing which track, at which moment, was the actual bottleneck.

The three-track method.

A DevTools performance trace of the product page shows three overlapping tracks on one timeline: the network track, the main-thread track, and the GPU/compositor track. The senior method for diagnosing any slow page:

1. Find the user-facing symptom. A late LCP marker. A long interaction in the Interactions track. A red layout-shift marker.
2. Drop to the moment that symptom occurred and ask which track was the constraint.
   • Late LCP + hero still on the network track at LCP time → network or discovery problem (break 1).
   • Late LCP + hero finished early + main thread solid → render-blocking JS, element-render-delay.
   • Slow interaction + long main-thread task overlapping it → hydration or heavy handler (breaks 3 and 5).
3. Name the constraint as: “this track, at this moment.” That is a fixable statement. “The page is slow” is not.

This converts “the page is slow” into “the main thread was blocked by the hydration long task from 1.6 s to 2.5 s, and the user’s tap at 2.0 s queued behind it.” That is something you can fix.

The hydration deep-dive — where five pieces meet.

Hydration is the hinge of the whole trace, so it is worth one more pass. It is the React reconciler (lesson 05) running in a special mode: instead of createRoot building fresh DOM, hydrateRoot walks the component tree and adopts the existing server DOM. The render phase runs — your components execute, the fiber tree is built — but the commit phase, instead of inserting nodes, attaches event listeners and runs effects.

Hydration is gated by the JavaScript bundle: nothing hydrates until V8 (lesson 03) has parsed, compiled, and begun executing that bundle. It is one or more tasks on the event loop (lesson 01), and a large eager hydration is one long task that blocks input — which Core Web Vitals (lesson 07) records as poor INP for any interaction in that window. And the entire cost exists only because the page was server-rendered (lesson 06) in the first place. Hydration is where five of the seven browser lessons meet.

The first-paint deep-dive — another dense intersection.

The other dense intersection is the first-paint sequence. The render pipeline (lesson 02) needs the DOM and CSSOM; the DOM comes from the HTML parser, the CSSOM from CSS parsing — both main-thread tasks (lesson 01). The JavaScript that may modify the DOM before first paint must first be parsed and compiled by V8 (lesson 03), and if that JS is render-blocking, the paint waits for it. The composite stage hands layers to the GPU. LCP (lesson 07) fires when the largest element of that paint lands.

So “first paint” is not one mechanism — it is the render pipeline, the parser, V8, and the compositor, coordinated, with a Core Web Vital watching the result. No layer is an island; every real page is the whole stack at once.

The capstone discipline — three moves.

Step back from the page and look at the method itself. The senior skill this whole chapter builds toward is not memorising eight layers — it is a discipline of diagnosis. It has three moves:

1. Measure before you touch. A real trace and field RUM, never a guess, because the symptom routinely names the wrong layer. The junior who optimised the 12 ms handler measured nothing — they guessed.

2. Find the constraint, not a constraint. On the overlapped timeline there is always one track, at one moment, that is the actual bottleneck — optimising anything else moves a number that was not the problem. The 900 ms hydration long task was the constraint; the handler was not.

3. Fix the dominant cause, then re-measure. Because the layers interact, a fix in one layer changes the budget in others, so the trace after the fix is a new diagnosis, not a confirmation. Shrinking the bundle changes the V8 cost, which changes the hydration long task, which changes the INP profile — the new trace may reveal a secondary bottleneck.

A junior engineer optimises what they know how to optimise; a senior engineer optimises what the trace says is the constraint. The eight layers are the map; the discipline is knowing the map does not tell you where the problem is — the measurement does.

Production observability — turning understanding into a system.

The end-to-end mental model becomes a production practice through layered telemetry, each layer watching the boundary it owns:

• RUM with web-vitals captures LCP, INP, and CLS with attribution — the LCP element, the INP script, the CLS source — so a regression names its own layer.
• Long Animation Frames (PerformanceObserver long-animation-frame entries) attribute slow frames to specific scripts, catching the hydration long task and heavy handlers.
• Server-side tracing watches TTFB and the data-fetch path.
• Service-worker telemetry watches cache hit rates and fetch-handler duration.
• Synthetic CI gate — a throttled Lighthouse or Playwright trace on every PR — catches the obvious regressions before merge.

Because a slow page is a chain problem, the monitoring must cover every link. And each metric must carry enough attribution to point back to the layer that broke. That is how whole-chain understanding stops being a debugging skill and becomes a system that catches the break for you.