Core Web Vitals for Frontend Interviews

Core Web Vitals for Frontend Interviews

"How would you measure and improve this page's performance?" is a near-universal frontend interview question, and the expected vocabulary is Core Web Vitals — not generic answers like "minify the JS." This builds on the event loop, explained, since several of the fixes below are really event-loop problems in disguise.

The three metrics, and their exact thresholds

Per web.dev, Core Web Vitals are always assessed at the 75th percentile of page loads, split by mobile and desktop — a few fast loads don't hide a slow p75.

Metric	Good	Needs improvement	Poor
LCP (Largest Contentful Paint)	≤ 2.5s	2.5s – 4.0s	> 4.0s
INP (Interaction to Next Paint)	≤ 200ms	200ms – 500ms	> 500ms
CLS (Cumulative Layout Shift)	≤ 0.1	0.1 – 0.25	> 0.25

One thing worth knowing cold for an interview: INP replaced FID as the official interactivity Core Web Vital in March 2024. If you're asked about FID, mention that it's been superseded — FID only measured the delay before an interaction started processing, while INP measures the full duration of a representative interaction through to the next visual update, which is a much more complete picture of "does this page feel responsive."

LCP: what actually counts, and what slows it down

LCP is the render time of the largest visible content element in the viewport — typically a hero image, a large block of text, or a background image via CSS. Common causes of a slow LCP:

• A slow server response time (high TTFB) before the browser can even start rendering.
• Render-blocking CSS/JS delaying first paint.
• The LCP image itself being large, unoptimized, or lazy-loaded when it shouldn't be — a lazy-loaded hero image is the LCP element, so lazy-loading it makes LCP worse, not better.
• Client-side rendering that requires JS to execute before any content appears.

INP: why it's about the whole interaction, not just the click handler

A slow INP usually isn't one giant blocking function — it's death by a thousand cuts: long tasks on the main thread that delay the browser from processing the next paint after a click, keypress or tap. Because JavaScript is single-threaded, any long synchronous task — a big re-render, an expensive computation, unbatched state updates — blocks the browser from responding to the next interaction, not just the current one.

The fix vocabulary interviewers want to hear: breaking up long tasks (yielding back to the main thread), debouncing expensive work rather than running it on every keystroke (see debounce vs. throttle), and avoiding layout thrashing (reading and writing to the DOM in alternating, forced-synchronous-layout patterns).

CLS: layout shift is almost always a missing dimension

Cumulative Layout Shift measures unexpected movement of visible elements. The classic causes:

• Images or embeds without a width/height (or aspect-ratio) reserved, so the browser doesn't know how much space to leave before the image loads.
• Web fonts swapping in and reflowing text (FOIT/FOUT).
• Content — especially ads or banners — injected above existing content instead of below it, or without a reserved slot.

The fix in almost every case is the same: reserve the space up front (explicit dimensions, aspect-ratio, min-height) so nothing has to move once real content arrives.

Talking about this in an interview

A strong answer names the specific metric, the specific mechanism causing it, and a specific fix — not "I'd optimize the images." For example: "LCP is likely slow because the hero image has no explicit dimensions and isn't preloaded — I'd add width/height, use fetchpriority=\"high\" on it, and make sure it isn't behind a client-side data fetch." That's a Security/Performance-style answer graded on specificity, the same way frontend system design interviews are.

Practice explaining this out loud

Frontend Interview Prep includes frontend system design practice where performance trade-offs like these come up directly — useful for rehearsing the specific-metric-specific-fix pattern interviewers are listening for.

Frequently asked questions

What replaced FID as a Core Web Vital?

INP (Interaction to Next Paint), which became a stable Core Web Vital in March 2024. INP measures the full duration of a representative interaction, not just the initial input delay that FID measured.

What is a "good" LCP score?

2.5 seconds or less, measured at the 75th percentile of page loads. 2.5–4.0 seconds is "needs improvement," and anything above 4.0 seconds is "poor," per web.dev's published thresholds.

Why does adding width and height to an image improve CLS?

It lets the browser reserve the correct amount of space for the image before it finishes loading, so nothing else on the page has to shift once the image appears — the single most common fix for layout-shift issues.