Browser & Frontend Runtime
Core Web Vitals: multiple-choice review
Crux Multiple-choice synthesis across the Core Web Vitals unit — thresholds, the field-vs-lab verdict, LCP phases, the hydration INP trap, CLS scoring, and shared-budget tradeoffs.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each mirrors a call you make reading a real PageSpeed report or a field dashboard — not a definition to recite, but which number to trust and which fix to reach for.
Goal
Confirm you can connect the three thresholds, the field-vs-lab verdict, the phase and part decompositions, and the shared performance budget — the synthesis the individual lessons built toward.
Quiz
Completed
PageSpeed Insights shows LCP 1.8 s in the Lighthouse section (green) and LCP 3.9 s at field p75 (red). The team says 'the lab says we are fine, ship nothing.' What is the correct read?
Heads-up Reproducible is not representative. The lab fixes one device and network on purpose — that makes it good for debugging, not for the verdict. Ranking uses field p75.
Heads-up A lab number and a field percentile are different kinds of measurement; averaging them is meaningless. The field p75 stands on its own as the user-experienced, ranking-relevant value.
Heads-up TTFB is one phase of LCP, not a replacement. Both LCP numbers are valid — they answer the synthetic-vs-real-user question differently — and the field one is the verdict.
Quiz
Completed
A server-rendered page has poor INP, but only for interactions in the first ~3 seconds; after that every tap is fine. The tap handlers run in 8 ms. Where is the problem and what is the fix?
Heads-up If handlers were the cause, INP would be poor for every interaction, not only the early ones. An 8 ms handler cannot produce a time-bounded pattern — that signature points at hydration.
Heads-up Server latency affects TTFB and LCP, not the main-thread interaction latency INP measures — and it would not produce an early-only INP pattern.
Heads-up Image size drives LCP load time. It does not block the main thread for interactions; that is a JavaScript/hydration concern, which is what the early-only pattern points to.
Quiz
Completed
The web-vitals LCP attribution shows TTFB 280 ms, load delay 90 ms, load time 3510 ms, render delay 240 ms. The element is a 3.8 MB 4000×3000 JPEG hero. What is the highest-leverage fix?
Heads-up Load delay is only 90 ms — discovery is already fast. fetchpriority/preload fix load DELAY, not load TIME. Fixing the wrong phase is the classic LCP mistake.
Heads-up TTFB is 280 ms — a small slice. Shaving it does almost nothing against a 3510 ms load time. Read the phase split first; fix the dominant phase.
Heads-up Render delay is 240 ms. Inlining CSS targets render-blocking resources, which are not the bottleneck here. The 4 MB image download is.
Quiz
Completed
A single layout shift moves a half-viewport element down by 20% of viewport height, with no user interaction in the prior 500 ms. What does it score, and is the page's CLS automatically poor?
Heads-up The score is the product, not the sum: impact fraction × distance fraction = 0.5 × 0.2 = 0.1. Adding them is the common arithmetic error.
Heads-up Backwards — the 500 ms exclusion removes shifts that FOLLOW a user interaction. An un-caused shift is exactly what CLS punishes; this one scores 0.1.
Heads-up There is no per-shift pass/fail threshold. CLS is the summed worst 5 s session window; a lone 0.1 shift sits on the good border, not in 'poor'.
Quiz
Completed
A team inlines the full critical CSS bundle to cut LCP render delay by 400 ms. LCP improves in the lab, but you push back before merge. Why?
Heads-up Inlining critical CSS does not inherently spike INP — it removes a render-blocking request. The real concern is the HTML-size/TTFB tradeoff, whose sign depends on connection speed and bundle size.
Heads-up Render-blocking CSS directly delays the LCP element's paint (render delay), so inlining critical CSS can help LCP. The catch is the TTFB cost, not irrelevance.
Heads-up Lab fixes can absolutely move the field — that is the point of debugging in the lab. The issue is verifying the net effect across all three metrics, not dismissing lab results.
Quiz
Completed
A SPA ships green Core Web Vitals on initial load, but users complain that client-side route changes feel sluggish. Why might the metrics miss this, and what is the fix?
Heads-up Green initial-load numbers do not cover soft navigations. Snappy first load plus sluggish route transitions is a real, historically under-measured failure mode in SPAs.
Heads-up CrUX is not wrong; the gap is that soft navigations emit no standard load event, so vitals were not attributed to them. Chrome's soft-navigation support and explicit RUM instrumentation close the gap.
Heads-up SPAs can hit good vitals — the issue is measurement coverage of route changes, not an architectural impossibility. Instrument soft navigations rather than abandoning the SPA.
Recap
The unit’s through-line is one diagnostic discipline: LCP/INP/CLS are field metrics at p75 (≤2.5 s, ≤200 ms, ≤0.1), and only CrUX field data is the ranking verdict — debug in the lab, judge in the field. LCP is read by its four-phase split and INP by its three-part split, so you fix the dominant phase, not the convenient one. The early-only INP pattern means hydration, not handlers. CLS is impact × distance summed over the worst 5 s window, with a 500 ms post-interaction exclusion. And all three share a budget — every change must be measured against all of them, never one in isolation.