Skip to content

Core Web Vitals: LCP, INP and CLS

Core Web Vitals are Google’s field metrics for page experience: LCP measures when the largest visible content finishes rendering, INP measures the worst typical delay from user input to the next visual update, and CLS measures unexpected layout movement. They are usually assessed at the 75th percentile over a 28 day field-data window.

The problem Core Web Vitals solve is that “slow page” is too vague to debug. Loading, responsiveness, and visual stability fail for different reasons and feel different to users. A page may look ready while JavaScript blocks every tap, or it may respond quickly while adverts and images push content around. The metrics separate those failure modes so engineers can stop applying generic performance fixes and identify the actual user-visible defect.

LCP is taken from the browser’s rendering timeline: it watches candidates such as hero images, headings, and large text blocks, then records when the largest one in the viewport is painted. INP listens to real interactions such as clicks, taps, and typing, groups the event work and rendering delay, then reports the slowest meaningful interaction for the visit. CLS adds up unexpected movement between rendered frames, ignoring shifts caused by recent user action.

The trade-off is that these are user-experience proxies, not a full performance model. Field values depend on devices, networks, geography, cache state, browser support, and traffic mix. The 75th percentile over 28 days deliberately reflects most real users rather than a clean developer machine, but it also means fixes are not instantly visible in field reports. Lab tools are faster for diagnosis, while field data is the evidence users actually experienced.

Engineers meet Core Web Vitals in Search Console, Chrome UX Report-style datasets, PageSpeed Insights, Lighthouse, browser performance traces, and real-user monitoring. In practice, the first move is triage: bad LCP sends you toward server time, render-blocking resources, images, fonts, and client rendering; bad INP toward long tasks, event handlers, hydration, and main-thread contention; bad CLS toward missing dimensions, late content, font swaps, adverts, and injected UI.

Common questions

Does a bad Core Web Vitals score mean the whole site is slow?
Not necessarily. A failing value usually points to a specific kind of user-visible problem. Bad LCP means the main content appears late. Bad INP means interaction feedback is delayed. Bad CLS means the layout moves unexpectedly. Treat the metric as a diagnosis category before choosing optimisations.
Why use the 75th percentile instead of an average?
An average can hide a large group of users having a poor experience, especially on slower devices or networks. The 75th percentile asks whether most visits are acceptable while still paying attention to worse real-world conditions. It is a practical compromise between optimising only for the median and chasing every extreme outlier.
Can Lighthouse prove that Core Web Vitals are fixed?
Lighthouse is useful for reproducing and investigating issues, but it is lab data from a controlled run. Core Web Vitals decisions are commonly based on field data over a 28 day window, so the honest answer is that Lighthouse can suggest a fix is plausible, while real-user data confirms whether it worked.