Diagnosing a Slow Page — Cheat Sheet

FE Lead prep · ref 04

The loop (measure, don't guess)

RUM → reproduce in lab → localize to a metric/phase → fix root cause → verify in field

	RUM / field	Lab / synthetic
job	find & prioritize	explain & reproduce
answers	whether / for whom (metric, page, segment)	why (flame chart, waterfall)
tool	CrUX / RUM vendor / `PerformanceObserver`	Lighthouse + DevTools Perf panel

Rule: RUM hands the lab a target. Optimizing a lab number no real user hits = wasted sprint.

Reading the flame chart

x = time, y = call stack — top calls the events below; wide block = slow.
Long task = main-thread work >50ms → red triangle, red shade past 50ms. Kills INP.
Tracks: metrics (LCP/CLS auto, INP on interaction) · Network (waterfall) · Main (your JS).
Performance Insights view auto-flags LCP sub-parts, render-blocking, 3rd-party, dup JS.

Slow LCP → 4 sub-parts

Sub-part	Fix if it dominates
TTFB	CDN / edge / backend
Load delay	preload + `fetchpriority=high`
Load time	compress, AVIF, `srcset`
Render delay	inline critical CSS, defer JS

Poor INP → 3 phases

Phase	Look / fix
Input delay	long task before handler → break up
Processing	heavy handler → make cheap, defer
Presentation	big re-render → virtualize

Other tools to name

Coverage → unused JS/CSS → code-split / delete
Network waterfall → request chains → flatten (preconnect/preload); oversized assets
Bundle analyzer → what's in the bundle, dup deps, heavy lib to swap
PerformanceObserver → raw entries (the API under RUM)
web-vitals (Google/Chrome) → the metric, computed to match CrUX. onLCP/onINP/onCLS + web-vitals/attribution for the why

RUM vendors to name

Free / Google field → CrUX (PSI, CrUX API, BigQuery, CrUX Dashboard) — aggregated, 28-day, not per-session
Perf-native RUM → SpeedCurve (LUX), Akamai mPulse, DebugBear, Calibre, Raygun
APM suites w/ RUM → Datadog, New Relic, Dynatrace, Sentry, Grafana Faro
Roll-your-own → web-vitals→sendBeacon→data lake (or GA4 / Cloudflare Web Analytics / Elastic APM)

Lead one-liners (memorize)

The loop “RUM to find it, lab to explain it. Field says which metric & which users; the flame chart says why. Fix the root cause, verify in the field.”

Systemic “Fix the class of issue, not the page — then a CI budget so it can't recur. Guessing from my laptop is how teams waste a sprint.”

web-vitals “I ship Google's web-vitals, not a hand-rolled observer — so my field numbers match the CrUX numbers I'm graded on, and attribution names the slow element.”

Sources: Chrome — Performance panel · web.dev — Optimize LCP · MDN — RUM vs synthetic · GoogleChrome/web-vitals

Don't fail the interview

1. RUM first, always. Never start optimizing from your fast laptop.

2. Throttle the lab (CPU 4×, slow 4G) to mimic the slow segment — else lab lies.

3. Read the LCP sub-part — load delay ≠ load time ≠ TTFB ≠ render delay; each has a different fix.

4. Fix the class, not the instance + add a CI guardrail. "Systemic, not a quick fix."

5. Don't hand-roll RUM. CLS = largest session window, not the sum; INP spans the whole visit — ship web-vitals so your field numbers match CrUX.

6. CrUX ≠ session RUM. It's aggregated/28-day — for debugging one slow session you need a vendor or your own web-vitals→beacon pipeline.