Core Web Vitals Interview Questions

LCP does measure the render time of the largest content element visible in the viewport from the moment the user begins navigation. Google's thresholds classify LCP ≤ 2.5 s as 'Good', 2.5–4.0 s as 'Needs Improvement', and > 4.0 s as 'Poor'. Both parts of the statement are correct.

The original Core Web Vitals were LCP (loading), First Input Delay / FID (interactivity), and CLS (visual stability). In March 2024, Google officially replaced FID with Interaction to Next Paint (INP), which better captures the full responsiveness of a page across all user interactions rather than only the first one.

The three Core Web Vitals are LCP (loading), INP (interactivity — which replaced FID in March 2024), and CLS (visual stability). First Contentful Paint (FCP) is a diagnostic metric reported in Lighthouse and PageSpeed Insights, but it is NOT one of the three Core Web Vitals. LCP, INP, and CLS are the metrics that feed directly into Google Search ranking signals.

Google defines "Good" thresholds for the three Core Web Vitals as: LCP ≤ 2.5 s (measures when the largest above-the-fold content element becomes visible); CLS < 0.1 (a unitless score measuring unexpected layout shifts); and INP < 200 ms (measures end-to-end latency of user interactions). Values between the Good and Poor thresholds are rated "Needs Improvement".

LCP measures when the largest content element (commonly a hero image) becomes visible. fetchpriority="high" on the hero <img> tells the browser to prioritise downloading that resource early, directly shortening its fetch time. <link rel="preload" as="image"> kicks off the LCP resource request before the parser even reaches the <img> tag, reducing discovery latency. Serving via a CDN reduces TTFB, which shortens the time before any byte of the page—including the LCP resource—can begin downloading. loading="lazy" is actively harmful for the LCP element because it intentionally delays its fetch. Deferring an analytics script that is already at the end of <body> and is therefore neither render-blocking nor related to the LCP element; moving a non-blocking end-of-body script to defer has no meaningful effect on LCP.

INP measures the latency of discrete interactions from input until the next frame is painted, and is decomposed into input delay, processing time, and presentation delay. Yielding long tasks with scheduler.yield() or setTimeout keeps the main thread from being blocked when the user interacts, which reduces the input delay portion of INP for subsequent interactions — a well-established optimization in Google's INP guidance. Reducing DOM size and expensive style recalculations triggered by handlers shortens the layout/paint work the browser must do after the event callback, directly reducing presentation delay. Switching image formats to WebP reduces page weight and affects LCP/transfer cost, but does not change how quickly the main thread responds to an interaction. HTTP/2 concurrent-stream limits are a network-multiplexing concern unrelated to main-thread interaction latency. Unconditionally wrapping interaction-driven DOM updates in requestAnimationFrame defers the visual update to a later frame, which generally increases presentation delay for the measured interaction; Google's INP guidance specifically warns against using rAF as a blanket wrapper for interaction visual updates for this reason.

CLS is the only Core Web Vital that is not a time-based metric; it quantifies visual instability. Its score is the sum of (impact fraction × distance fraction) for each unexpected shift. The two most prevalent causes are unsized media (no reserved space) and late-injected content above the fold. The fixes directly address the reservation of layout space before resources load or content appears.

Each milestone is a strict data-dependency prerequisite of the next, giving a single uncontested total order. (s1) TTFB precedes everything — no HTML bytes means no parsing and no discovered <img>. (s2) The request for the image can only be dispatched after enough HTML has arrived to expose the tag or its preload hint, so s2 follows s1. (s3) The first image byte cannot arrive before the request has been sent, so s3 follows s2. (s4) The first paint of the image requires at least some image bytes to have been received and decoded (even progressive/streaming codecs need some bytes on hand), so s4 follows s3. (s5) The Web Vitals spec ties the LCP renderTime to the moment the element was first painted, so the entry cannot be recorded before that paint occurred; s5 follows s4. Note this version deliberately uses first-occurrence milestones (first byte, first paint) rather than completion gates, which sidesteps progressive-decode and tiled-rendering concerns — decode may overlap download and paint may overlap decode, but the first occurrence of each still respects this ordering.

The common mistake is equating INP with 'how long my event handler function took.' The metric is end-to-end — input arrival to next paint — so a slow INP can come from main-thread contention before the handler even starts, or from expensive layout/paint work after it finishes, not just from the handler's own code.

Cumulative Layout Shift (CLS) uses a session window model: shifts are grouped into windows of up to 5 seconds, with no more than 1 second between consecutive shifts. The page's CLS score is the maximum session window score. A 'good' CLS is ≤0.1. The impact fraction × distance fraction formula produces the shift score for a single shift. Importantly, layout shifts caused by user interactions (within 500 ms of a user gesture) are excluded from CLS to avoid penalizing intentional expansions. Size changes to elements already off-screen are also excluded. Understanding the session-window aggregation, the 500 ms interaction grace period, and what is/isn't excluded are classic staff-level CLS gotchas.