Lesson 04
Performance & Web Vitals
LCP, INP, CLS. They will ask you to define each.
1 · The 3 vitals, in plain English
🧠 in plain english
Imagine walking into a restaurant.
• LCP = how long before you can SEE the menu. (Bad: 5 minutes of staring at a wall.)
• INP = how long after you tap a menu item before the waiter responds. (Bad: 3 seconds of awkward silence.)
• CLS = how often the table tilts unexpectedly while you're eating. (Bad: soup keeps sliding.)
• LCP = how long before you can SEE the menu. (Bad: 5 minutes of staring at a wall.)
• INP = how long after you tap a menu item before the waiter responds. (Bad: 3 seconds of awkward silence.)
• CLS = how often the table tilts unexpectedly while you're eating. (Bad: soup keeps sliding.)
LCP
Largest Contentful Paint
target < 2.5s
When the biggest visible element shows up. Usually the hero image or main heading.
Fix: preload hero, server-render above-fold, AVIF/WebP, fetchpriority="high".
INP
Interaction to Next Paint
target < 200ms
Worst delay between a click/tap and what shows up next. Replaced FID in 2024.
Fix: break long tasks (scheduler.yield()), useTransition, web workers.
CLS
Cumulative Layout Shift
target < 0.1
Unexpected layout jumps. The page suddenly shifts as you're about to click.
Fix: width/height on images, reserve space for ads, font-display: optional.
2 · The 200ms INP budget — drag the sliders
You have 200ms from click → paint. Anything slower and INP fails. Drag each slider and see if you stay under budget.
40ms
30ms
60ms
50ms
200ms target
total 180ms · ✓ passes INP target (<200ms)
p75 is what matters. Google grades Core Web Vitals on the 75th percentile of real users. p50 hides the long tail. If your p75 INP is good, your median is great.
📣 say this in the interview
“I look at p75 INP, not p50 — Google grades on p75. And I track it via real user monitoring, not just lab data, because the lab lies about real-world conditions.”
3 · The debugging playbook
🧠 in plain english
A user says “your site is slow.” Don't guess. Don't blame the network. Do this in order:
- Reproduce. Same browser, same throttling, same auth state. If you can't repro, you can't fix.
- Pull RUM data. Sentry / Datadog session trace. Real user, real device, real session.
- Run Lighthouse + Performance tab on the repro. Look for: long tasks > 50ms (purple bars), layout/paint thrash, fetch waterfalls.
- Identify the cause. Bundle too big? Slow hydration? Render storm? n+1 fetch? Layout thrash?
- Fix targeted:
- Big bundle → code split, replace heavy deps
- Slow hydration → RSC, less client JS, “use client” at leaves not root
- Render storm → React DevTools Profiler → memo the right thing
- Slow effects → useTransition, useDeferredValue, web worker
- Verify in production with RUM. Add a perf budget to CI so it doesn't come back.
⚡ quick check
Your INP is 350ms (bad). Profiler shows a 280ms task in your search filter handler. What's the right fix?