Diagnosing a Slow Page

1The one rule: measure, don't guess

The single thing that separates a Lead answer from a junior one: you never optimize blind. You find where the time actually goes, fix that, and verify it moved. The loop:

1. RUM first — find the problem. Field data (real users, p75) tells you which metric, which page, and which segment (device, country, network) is slow. This is where you decide what's worth fixing.
2. Reproduce in the lab. Open DevTools, throttle to match the slow segment (mid-tier mobile CPU 4×, slow 4G), and record. Lab is reproducible and detailed — it's where you find why.
3. Localize to one metric/phase. Is it LCP (loading) or INP (responsiveness)? Then break that metric into its sub-parts (below) to point at one culprit.
4. Fix the root cause, then verify. Re-measure in lab to confirm, then watch RUM to confirm it moved for real users — not just your machine.

2RUM vs lab — two jobs, not rivals

Use them as a relay: RUM hands the lab a target. Optimizing a lab number that no real user hits is the classic waste. [MDN]

3Reading the Performance panel

Record a load (or an interaction) and you get a flame chart of the main thread. Three things to know:

• x-axis = time, y-axis = call stack. Events on top call the events below them. A wide block = something took a long time.
• Long tasks = any main-thread task > 50ms. DevTools flags them with a red triangle and shades the part over 50ms red. Long tasks are the enemy of INP — while one runs, the page can't respond.
• Tracks: the metrics row shows local LCP/CLS automatically, and INP once you interact; the Network track shows the request waterfall; the Main track is your JS.

Modern DevTools also has a Performance Insights view that auto-flags LCP sub-parts, render-blocking requests, third-parties, and duplicated JS — name it; it's the current workflow. [Chrome]

4The per-symptom playbook

Slow LCP → break it into 4 sub-parts

web.dev splits LCP into four phases — find which dominates, and the fix is obvious:

Source: web.dev — Optimize LCP

Poor INP → record the interaction, split 3 phases

Interact while recording; DevTools breaks the slow interaction into input delay / processing / presentation (Lesson 03). Then:

• Long input delay → the main thread was busy with a long task before your handler. Find that task in the flame chart, break it up / ship less JS.
• Long processing → your event handler is heavy. Make it cheap, defer non-urgent work.
• Long presentation → a giant re-render/commit. Virtualize, reduce DOM, content-visibility.

Other tools to name

• Coverage tool — highlights unused JS/CSS shipped to the page → code-split / remove dead code.
• Network waterfall — find request chains (A must finish before B is discovered) and flatten them with preconnect/preload; spot uncompressed or oversized assets.
• Bundle analyzer (webpack-bundle-analyzer / source-map-explorer) — what's in the bundle, duplicate deps, a heavy lib to swap.
• PerformanceObserver — the API your own RUM uses to capture LCP/INP/CLS/long-tasks from real users.

// minimal field measurement — feed your RUM
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) sendToRUM(entry);
}).observe({ type: 'largest-contentful-paint', buffered: true });

But that snippet gives you raw entries, not the metric. In production you ship Google's web-vitals library (npm web-vitals, by the Chrome team) — it encodes the rules that match how CrUX measures, the very numbers you're graded on:

• LCP = last entry before first interaction / page hidden — not just the last one you see.
• CLS = the largest session window of shifts (max 5s, 1s gaps), not the sum of all shifts. Easy to get wrong by hand.
• INP = worst interaction latency tracked across the whole visit.
• All three are only final when the page is backgrounded, so it reports on visibilitychange/pagehide.

import { onLCP, onINP, onCLS } from 'web-vitals';

function sendToRUM({ name, value, rating, delta, id }) {
  // rating = 'good' | 'needs-improvement' | 'poor'  (the p75 thresholds)
  navigator.sendBeacon('/rum', JSON.stringify({ name, value, rating, delta, id }));
}
onLCP(sendToRUM); onINP(sendToRUM); onCLS(sendToRUM);

// the attribution build tells you WHY, in the field:
import { onINP } from 'web-vitals/attribution';
onINP(({ value, attribution }) => {
  // attribution.interactionTarget → the element the user hit
  // inputDelay / processingDuration / presentationDelay → which phase was slow
});

Where the data lands — RUM vendors to name. The smart move isn't reciting brands, it's showing you know the categories and pick by constraint (cost, scale, privacy, build-vs-buy):

5The Lead move: systemic, not heroic

The toolkit grades root cause + systemic fix. So the answer isn't “I opened DevTools once” — it's a process and a guardrail:

• Find the class of problem, not the instance — “our INP regressions are almost always a new third-party tag's long tasks,” so you fix the category (a tag-loading policy), not one page.
• Instrument RUM on p75 by route + segment so you see regressions in the field, with alerting.
• Guardrail in CI — perf budget + Lighthouse gate (Lesson 03) so the same regression can't recur.
• Make the data shared — a dashboard the whole org reads, so performance is a team discipline.

6Check yourself — scenario quiz

Pick an answer; instant feedback. Push-back style, like the round.