What are Core Web Vitals?

What Core Web Vitals are

The Core Web Vitals are a small set of measures that Google defines to describe how a page feels to a real visitor. There are three: how fast the main content appears, how quickly the page responds when someone clicks, and whether the layout stays still while loading.

Each has a "good" threshold. Web.dev, Google's web performance site, gives them as 2.5 seconds for loading, 200 milliseconds for responsiveness and 0.1 for visual stability. A page passes when it meets all three at the 75th percentile, which means three out of four visits are at least that good. Mobile and desktop are assessed separately.

Web.dev says the three metrics are stable, and that stable metrics change no more than once a year. The page was last updated in October 2024, so check it for any later change.

Largest Contentful Paint: loading

Largest Contentful Paint (LCP) records when the largest image, video or block of text in the visible area finishes rendering. It stands in for "the main content has loaded". Web.dev rates it good at 2.5 seconds or less, needs improvement up to 4 seconds and poor above 4 seconds.

Web.dev's optimisation guide splits LCP into four parts: time to first byte, resource load delay, resource load duration and element render delay. It suggests roughly 40 percent for the first byte, 40 percent for downloading the resource and under 10 percent each for the two delays, as guidelines rather than strict rules.

Typical fixes follow from that. Never lazy-load the LCP image. Put the image in the initial HTML so the browser finds it early. Mark the main image with fetchpriority="high". Compress and resize it, and reduce server response time and redirects.

Interaction to Next Paint: responsiveness

Interaction to Next Paint (INP) measures how long the page takes to show a visual response after a click, tap or key press. It reports roughly the slowest interaction during the visit, ignoring outliers. Web.dev rates it good at 200 milliseconds or less, needs improvement up to 500 and poor above 500.

An interaction has three parts: input delay before handlers run, processing time while they run, and presentation delay until the next frame is painted. Long tasks on the main thread, slow event handlers and heavy rendering are the usual causes.

INP replaced First Input Delay, which only measured the delay of the first interaction. INP covers all of them, so a page that felt fine on load can still fail it. Common culprits are third-party scripts, chat widgets, large page scripts and oversized pages.

Cumulative Layout Shift: visual stability

Cumulative Layout Shift (CLS) scores how much visible content jumps around unexpectedly. Each shift is scored as the impact fraction times the distance fraction. If an element covers 75 percent of the viewport and moves a quarter of the screen height, that single shift scores 0.75 times 0.25, which is 0.1875. Good is 0.1 or less and poor is above 0.25.

Web.dev lists the usual causes: images and videos without dimensions, web fonts that swap with different sizing, ads and embeds that resize, and content injected above existing content. Fixes include setting width and height or an aspect ratio on images, reserving space for ads and embeds, and choosing a close fallback font.

Shifts that happen within half a second of a click or tap are treated as expected and excluded.

How to measure them: field and lab data

Field data comes from real visitors. The Chrome User Experience Report (Chrome User Experience Report, or CrUX) gathers it from Chrome users, and Google says it uses it for the page experience ranking factor. Search Console's Core Web Vitals report and PageSpeed Insights both draw on it.

Lab data comes from a simulated test in tools such as Lighthouse. It is repeatable and good for debugging, but web.dev stresses that only field measurement captures the full picture. INP cannot be measured in Lighthouse at all because no one interacts, so Total Blocking Time is used as a rough proxy.

Search Console groups similar URLs, rates each group by its worst metric and uses a 28-day window. After a fix, "Start Tracking" monitors the group for 28 days. Low-traffic pages may show "no data available", in which case use PageSpeed Insights or Lighthouse on that URL.

How much they matter for rankings and business

Google's page experience guidance says its ranking systems use Core Web Vitals and that good scores are recommended. It also says there is no single page experience signal, that good scores in reports do not guarantee top rankings, and that it will show the most relevant content even when page experience is sub-par. Treat vitals as a tie-breaker and a quality floor.

The business case is separate from ranking. A slow or jumpy page frustrates visitors at the moment they decide to enquire or buy. Fixing it supports conversion rate optimization as much as SEO.

Do not chase a perfect score at the expense of content. Google itself notes that chasing perfection for SEO purposes may not be the best use of time. Fix failing groups of pages, then move on.

A practical order of work

• Open the Core Web Vitals report in Google Search Console and note which metric and which URL group fail.
• Run PageSpeed Insights on one URL from that group and read the field data first, then the lab diagnostics.
• Fix the template, not the page: a change to a shared header or product template fixes the whole group.
• Deploy, then use Start Tracking and wait for the 28-day window.
• Re-test after every plugin, tag or theme change. See the technical SEO audit.