Core Web Vitals are three measurements of page experience: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness and Cumulative Layout Shift (CLS) for visual stability. Each has a target that a page should meet for most visits.
They sit alongside layout and markup choices in front-end web development, and each metric points to a specific kind of fault that designers and developers can fix.
What the three metrics measure
The Web Vitals programme was set up by Google, and web.dev describes the Core Web Vitals as the subset of Web Vitals that apply to all web pages, should be measured by all site owners, and will be surfaced across all Google tools. The set can change over time, and the current version covers loading, interactivity and visual stability.
The three thresholds below come from the same source. LCP is described there as the measure of loading performance: To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading. For responsiveness, the guidance reads pages should have a INP of 200 milliseconds or less. For visual stability, the CLS page states that Good CLS values are 0.1 or less. Poor values are greater than 0.25.
One more rule matters when reading reports. A page is judged on most visits, not the best ones: Tools that assess Core Web Vitals compliance should consider a page passing if it meets the recommended targets at the 75th percentile for all three of the Core Web Vitals metrics. A single fast test run therefore does not prove a page passes.
Largest Contentful Paint: how fast the main content appears
LCP answers a simple question: when did the biggest thing on the screen finish rendering? According to web.dev, LCP reports the render time of the largest image, text block, or video visible in the viewport, relative to when the user first navigated to the page. On many pages that element is a hero photograph or a large headline.
The element can be an img element, a video poster, an element with a CSS background image, or a block of text. The same article lists these types, including Block-level elements containing text nodes or other inline-level text element children. Knowing which element is the LCP candidate on a given page is the first step in improving the score, because every fix targets that one element.
Two image habits cause most of the avoidable delay. The optimisation guide says Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and it suggests a priority hint for the same element: It’s a good idea to set fetchpriority=”high” on an <img> element if you think it’s likely to be your page’s LCP element. The file itself also matters, and the comparison in image formats for web explains how format choice changes what the browser has to download.
Interaction to Next Paint: how quickly the page reacts
INP replaced an earlier responsiveness metric. web.dev explains that INP was initially developed as an experimental metric to address the runtime performance issues present on the web more comprehensively than First Input Delay (FID). Where the older measure looked at the first interaction, INP looks across the visit.
The definition is worth reading closely. INP observes the latency of all interactions a user has made with the page, and reports a single value which all (or nearly all) interactions were beneath. Clicks, taps and key presses all count. The measure ends when the browser can paint the next frame, which is why it captures visible feedback and not just the time spent in code.
The ratings are spelled out in three bands on the INP page:
| Rating | INP value |
|---|---|
| Good | 200 milliseconds or less |
| Needs improvement | Above 200 milliseconds and up to 500 milliseconds |
| Poor | Above 500 milliseconds |
Bands as defined in the web.dev INP guide.
When INP is poor, the usual cause is a busy main thread. The guide describes how An input delay occurs until event handlers start running, possibly caused by factors such as long tasks on the main thread. Heavy scripts, large third-party tags and expensive event handlers are the common sources, and breaking long tasks into smaller pieces gives the browser a chance to paint sooner.
Cumulative Layout Shift: keeping the page still
CLS is the metric users feel as a jolt: text moves just as they go to tap a link. web.dev defines the event precisely: A layout shift occurs any time a visible element changes its position from one rendered frame to the next. Each shift gets a score, calculated as layout shift score = impact fraction * distance fraction, so large elements that move far produce the biggest scores.
The same page names the usual culprits: images or videos with unknown dimensions, fonts that render larger or smaller than its initial fallback, or third-party ads or widgets that dynamically resize themselves. Each has a design-side fix. For media, the optimisation guide advises that you include width and height size attributes on your images and video elements. Alternatively, reserve the required space with CSS aspect-ratio or similar. For embeds and ad slots, a container with a reserved size does the same job.
Animation can also be done safely. According to the guide, Composited animations using translate can’t impact other elements, and so don’t count toward CLS. That makes transform-based motion the safer option for menus, banners and hover effects than animating properties that force the layout to be recalculated.
Markup quality plays a quiet part here as well. Pages built from clear structural elements are easier to keep stable and easier to maintain, a point developed in semantic html.
Measuring Core Web Vitals
Real-visit data and test-run data answer different questions. web.dev notes that While all of the Core Web Vitals are, first and foremost, field metrics, many of them are also measurable in the lab. Field data shows what visitors actually experienced; lab data is repeatable, which makes it useful while changes are still in development.
For field data, the same guide points to the Chrome User Experience Report, which collects anonymized, real user measurement data for each Core Web Vital and feeds tools such as PageSpeed Insights and the Search Console report. For lab work there is a useful stand-in for INP: Total Blocking Time (TBT) metric is lab-measurable and is a proxy for INP.
A practical routine is to check field data first to find which metric fails, then use lab tools to reproduce the problem, fix it and confirm the change. Fixing the metric that fails, rather than polishing the ones that already pass, keeps the effort proportionate.
Frequently asked questions
What counts as a good Core Web Vitals result?
web.dev sets the targets at LCP within 2.5 seconds, INP of 200 milliseconds or less and CLS of 0.1 or less, measured at the 75th percentile of page visits. A page passes only when it meets all three targets.
Does INP replace First Input Delay?
INP was developed to cover runtime responsiveness more fully than First Input Delay. Where FID considered the first interaction, INP considers interactions across the whole visit.
Can a single large image hurt the score?
Yes. If the largest image is the LCP element, a slow download or a lazy-loading attribute on it directly delays LCP. Missing width and height attributes can also cause layout shift when the file arrives.
Should lab tools or field data be trusted?
Both have a role. Field data reflects real visitors and decides whether a page passes, while lab data is repeatable and suits debugging during development.
