Core Web Vitals — Cheat Sheet

FE Lead prep · ref 03

The three (thresholds @ p75, field data)

Metric	Measures	Feeling	Good	Poor
LCP Largest Contentful Paint	loading	did it load?	≤ 2.5s	> 4s
INP Interaction to Next Paint	responsiveness	does it react?	≤ 200ms	> 500ms
CLS Cumulative Layout Shift	visual stability	does it hold still?	≤ 0.1	> 0.25

Pass = ≥ 75% of real visits hit “good”. Between good & poor = “needs improvement”. INP replaced FID, Mar 2024.

Lab vs Field

	Lab (Lighthouse/DevTools)	Field (CrUX / RUM)
what	one synthetic run	real users, p75
use	debug — tells you why	graded — tells you whether
INP?	can't (no real interaction; shows TBT proxy)	yes

Supporting metrics (the timeline)

TTFB → FCP → LCP → TBT/TTI → INP (bold = the vital)

Metric	Is	Good	Role
TTFB	req → first byte (server+net)	≤ 0.8s	caps LCP — precursor to all
FCP	first any content painted	≤ 1.8s	first sign of life → LCP
TBT	Σ long-task blocking after FCP	< 200ms (lab)	lab proxy for INP
TTI	main thread quiet ~5s post-FCP	—	deprecated (Lighthouse 10) → use TBT

INP = 3 phases

Phase	Is	Fix
Input delay	main thread busy	break long tasks, yield, less JS
Processing	handler JS runs	minimal sync work, debounce
Presentation	paint next frame	virtualize, `content-visibility`

Cause → fix (quick)

LCP: TTFB → CDN/SSR · blocking CSS/JS → inline/defer · slow hero → preload+fetchpriority=high, AVIF · never lazy-load hero
CLS: no img dims → aspect-ratio · late ads → reserve space · font swap → font-display+size-adjust

CLS formula

score = impact × distance

impact = viewport area the unstable element touches (before+after) ÷ viewport
distance = furthest move ÷ viewport's largest side
e.g. 0.5 × 0.2 = 0.10 (never add)
CLS = worst 5s session window (not page sum)
shifts <500ms after input = free

INP in React

Input delay: lazy+Suspense, trim hydration, less JS
Processing: startTransition / useDeferredValue (heavy update non-urgent), useMemo / Web Worker
Presentation: virtualize (react-window), React.memo, content-visibility
Rule: keep the onChange click path cheap + urgent

Lead one-liners (memorize)

The three “LCP = did it load, INP = does it react, CLS = does it hold still. Good = 2.5s / 200ms / 0.1, at p75 of real users.”

Lab vs field “Lab tells you why; field tells you whether. I debug in Lighthouse but I'm graded on p75 field data.”

Timeline “TTFB → FCP → LCP is the loading timeline; TBT is the lab proxy for INP. TTI is legacy — I quote TBT now.”

Platform mapping

LCP → listing page: SSR/stream + edge cache + preload hero photo (AVIF via CDN)
INP → filters/date-picker: light handlers, code-split, avoid blocking hydration
CLS → image cards: fixed aspect-ratio, reserve space for late prices/badges
Guardrail → RUM dashboard + CI performance budget so regressions can't merge

Sources: web.dev — INP · Google — Core Web Vitals · web.dev — thresholds

Don't fail the interview

1. It's field data at p75, not your laptop. Debug in lab, graded in field.

2. Lighthouse can't measure INP (no real interactions) — green lab ≠ good INP.

3. INP ≠ FID. FID = first interaction's input delay only; INP = full latency, all interactions.

4. Never lazy-load the LCP element (hero). Lazy-load below the fold only.

5. Lead answer = RUM p75 + perf budget in CI, not “I ran Lighthouse.”

6. TTI is deprecated (Lighthouse 10, too variable). Lab responsiveness = TBT; field = INP. Citing TTI dates you.

7. TTFB caps LCP — a slow first byte means no preload will save you. Fix the server/CDN first.

8. CLS = impact × distance (multiply, never add), worst 5s session window; sub-500ms-post-input shifts are free.

9. Bundle budget ≠ Lighthouse budget. Bundle gates the artifact (JS/CSS bytes); Lighthouse gates the rendered page (real LCP/CLS + images + 3rd-party). Run both in CI (@lhci/cli); fails the build. budget.json OR assertions, not both.