What are Core Web Vitals? A website speed optimization guide with LCP, INP and CLS

Core Web Vitals is the set of metrics Google uses to evaluate real user experience on a web page through three measurements: LCP for loading, INP for interaction response and CLS for visual stability. For a good experience, LCP should remain at or below 2.5 seconds, INP at or below 200 milliseconds and CLS at or below 0.1, with these thresholds met in at least three quarters of visits. The practical answer to “what are Core Web Vitals” is this: these three metrics are not a test score, but a measure of how the website feels to real visitors.

Website speed optimization therefore starts by finding which of the three metrics is struggling and why, rather than raising the score given by a tool. This guide explains what each metric measures, the thresholds defined by web.dev, how to read PageSpeed Insights and Search Console reports, and solutions to the most common causes of poor metrics. The explanations apply to every website built with WordPress, a ready-made platform or custom software; only the implementation tools change.

What are Core Web Vitals and which experience do they measure?

Core Web Vitals are the three fundamental metrics within Google’s Web Vitals initiative that it considers applicable to all web pages, measuring loading, interaction and visual stability. While other Web Vitals metrics remain specific to particular tools or scenarios, these three serve as a common language in Search Console, PageSpeed Insights and Chrome developer tools. The set is not permanent; web.dev says changes to definitions and thresholds will be announced in advance and follow an annual schedule.

The last major change to the set occurred in 2024: FID, which looked only at the delay of the first interaction, was retired, and INP, which tracks all interactions on the page, replaced it as a stable metric. This is why FID thresholds still appearing in older guides are misleading. The current set can be remembered through three abbreviations:

• LCP (Largest Contentful Paint): The time taken for the largest content element in the initially visible part of the screen to load and render; represents loading speed.
• INP (Interaction to Next Paint): The time taken for the page to respond visually to a click, tap or keypress; represents responsiveness.
• CLS (Cumulative Layout Shift): The amount of unexpected movement of elements on the page; represents visual stability.

LCP, INP and CLS thresholds: Good, needs improvement and poor

For the three metrics to count as “good,” the limits specified on web.dev’s Core Web Vitals page are 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS. Google Search Console applies the same limits in a three-tier table:

The thresholds apply to the 75th percentile of page loads rather than a single visit, and mobile and desktop are assessed separately. In practice, this means that if LCP is below 2.5 seconds in three quarters of visits, the page passes this metric; the remaining slow visits do not spoil the result on their own. To pass the assessment, all three metrics must be in the good range; a page with two good metrics and one poor metric does not count as passing.

What is LCP? Time for the main content to reach the screen

LCP is the time from when the page starts opening until the largest image, video or text block in the viewport is rendered on screen. It is considered representative of loading performance because it is the closest measure to the visitor’s feeling that “the page has loaded.” Eligible elements include img tags, image elements inside SVG, video poster images or first frames, background images loaded with url() in CSS, and block elements containing text. Elements covering the entire screen and serving as backgrounds are not counted.

web.dev divides LCP time into four subparts that add up to the full value. Knowing which part takes a long time determines which correction will actually work:

1. Time to first byte (TTFB): The browser receiving the first byte of the HTML document from the server.
2. Resource load delay: The gap between receiving the HTML and starting to download the LCP image.
3. Resource load duration: Downloading the LCP image or the font needed for text.
4. Element render delay: The wait between downloading the resource and rendering the element on screen.

The goal is to bring the two parts called “delay” close to zero. If the bottleneck is in another part, compressing the image will not reduce LCP; the saved time often shifts into render delay.

What is INP? How quickly the page responds to interaction

INP measures the time between clicks, taps and keyboard interactions on the page and the browser drawing the next frame on screen, reporting the slowest interaction observed during the visit. For visits with many interactions, one highest value is excluded for every 50 interactions to filter outliers. Scrolling and hovering over an element are not included in INP; opening a menu, adding a product to the cart or typing in a form field are included.

An interaction’s latency consists of three stages, each with a different source. Input delay occurs while the main thread is busy with another task, usually parsing and executing downloaded JavaScript. Processing duration is the execution of interaction-related code; presentation delay is the time the browser takes to render the result on screen. Interactions during page loading often produce the worst INP values because they coincide with the main thread’s busiest moment.