Core Web Vitals: LCP, INP and CLS explained

Core Web Vitals describe three aspects of experience: loading with LCP, responsiveness with INP and visual stability with CLS. The recommended targets are LCP at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1.

Assessment uses the 75th percentile of visits, separately for mobile and desktop. It does not reduce a whole site to one test on one computer.

Largest Contentful Paint measures when the largest eligible image or text block visible in the viewport is rendered. It usually approximates the point when the main content at the start of a page becomes visible.

• To diagnose a slow LCP, identify the measured element first.
• Then inspect server response, redirects, render-blocking resources, media loading and client-side rendering.
• The right correction depends on the observed cause.

Interaction to Next Paint observes latency for clicks, taps and keyboard input during a visit. A high INP may come from long work on the main thread, expensive JavaScript or a large rendering update triggered by an interaction.

Field measurement is particularly important for this metric. Lighthouse cannot measure real INP without user interactions; it uses Total Blocking Time as a related laboratory diagnostic.

Cumulative Layout Shift measures unexpected movement of visible content. An image without reserved space, a component inserted late or some font behaviour can move a button or text during a visit.

Declare media dimensions, reserve room for components loaded later and inspect complete user journeys. A test of initial page load alone may miss a shift that happens after an interaction.

PageSpeed Insights can show field data from the Chrome User Experience Report when it has a sufficient sample. It also runs Lighthouse in a simulated environment. The former describes past visits; the latter helps reproduce and debug causes.

• They can differ because of devices, networks, content and interactions.
• Use field data to monitor delivered experience and laboratory data to investigate.
• Missing field data does not mean that a page is either good or poor.

Field data comes from the Chrome User Experience Report, fed by visitors who use Chrome, have accepted usage-statistics sharing and visit a public page. It is aggregated over a rolling twenty-eight days and published per URL when the volume is sufficient, otherwise per origin, meaning for the whole site.

A Brussels small-business site with a few hundred visits a month often does not reach the per-URL threshold and sometimes not the per-origin one either. In that case PageSpeed Insights shows only the laboratory test, and Search Console leaves the Core Web Vitals report empty. That is not a fault of the site; it is a statistical limit.

Two solutions exist. The first: install a site-specific field measurement through a small library that sends LCP, INP and CLS from every visit to an analytics tool, which yields real data from the first visitors. The second: accept the laboratory as a guide and verify on real devices, simulating an average mobile connection.

The time to LCP splits into four pieces: the server’s response time for the HTML, the delay before the browser requests the main resource, the load time of that resource, and the delay between its arrival and its rendering. Each piece has its causes and its fixes.

A slow server — saturated shared hosting, a CMS without caching, chained redirects — is fixed by caching or a change of hosting. A high discovery delay means the main image is loaded by JavaScript or CSS rather than declared in the HTML; the solution is to declare it directly and mark it as high priority.

• A long load comes from the image’s weight or format, and is fixed by resizing and conversion.
• A late render after arrival indicates that blocking CSS or JavaScript is holding back display.
• Measuring the four parts, which browser developer tools allow, avoids fixing at random.

INP keeps, for a visit, one of the slowest interactions — click, tap, keystroke — excluding extreme outliers. A page can therefore load quickly and score poorly on INP if opening the mobile menu, selecting a variant or submitting a form triggers heavy work.

The usual culprits are third-party scripts listening to every click, animation libraries recalculating the whole page, event handlers doing too much synchronously, and fully client-rendered sites on modest phones. The laboratory’s Total Blocking Time helps spot long tasks, but only field measurement identifies the precise interaction.

Fixes consist of doing less work at the interaction: deferring what is not needed for immediate visual feedback, splitting long tasks, removing scripts that bring nothing, and giving instant visual feedback even if processing continues behind. A page that responds in under two hundred milliseconds feels instant, whatever the total time.

A laboratory test measures CLS during the initial load, in a fixed window. Real shifts often happen later: a consent banner that pushes all content down instead of overlaying it, an image loaded on scroll without reserved space, a fallback font replaced by the final font with a different width, a block inserted after a network call.

To find them, browse the site on a real phone with a throttled connection, watching what moves. Browser developer tools can also record a session and list every shift with the element responsible.

The fixes are almost always the same: declare the dimensions of every image and video, reserve space for components inserted later, overlay banners instead of inserting them into the flow, and configure font display to limit width changes. None requires a redesign; all require having seen the shift.

Once a month, open the Core Web Vitals report in Search Console if available, and note the number of good, needs-improvement and poor URLs, on mobile and desktop. A month-to-month change is a signal, not an alarm; two consecutive months in the same direction deserve an investigation.

Then test three representative templates — home, service or product page, article — in PageSpeed Insights, and compare the laboratory metrics with the previous month’s, bearing in mind that they vary by a few percent from one test to the next. Record the results in a simple table, with the date and the changes made to the site in between.

• That table becomes the site’s memory.
• When a metric degrades, it shows which release coincided with the degradation, which reduces the investigation to a few minutes.
• Without it, every performance problem starts from scratch.

Google recommends good Core Web Vitals for users and says this recommendation, together with other aspects of page experience, aligns with what its core ranking systems seek to reward. A green result still guarantees no ranking, traffic or conversion outcome.

Start with the affected page templates and metric, confirm the cause, implement the correction, test for regressions and then monitor field data. Time and effort cannot be estimated responsibly before diagnosis.