Core Web Vitals are three measurements Google uses to describe how a page feels to a real visitor: how fast the main content appears, how quickly the page responds when someone taps or clicks, and whether things jump around while it loads. They show up in Search Console, in PageSpeed Insights and in most SEO tools, usually in red.
They matter for two reasons. They're part of how Google assesses page experience, and, more directly, slow and jumpy pages lose visitors before they read anything. Relevance and content still decide most rankings, so treat good vitals as a baseline to reach rather than a trick to rank.
The three metrics
- LCP, Largest Contentful Paint: how long until the biggest thing in view, usually the hero image or headline, has rendered. Good is 2.5 seconds or less; over 4 seconds is poor.
- INP, Interaction to Next Paint: how long the page takes to visibly respond after a click, tap or key press, across the whole visit. Good is 200 milliseconds or less; over 500 is poor. It replaced FID in 2024.
- CLS, Cumulative Layout Shift: how much content moves unexpectedly while the page loads, such as a button sliding down as an image appears. Good is 0.1 or less; over 0.25 is poor.
A page passes when it hits the good threshold for all three at the 75th percentile of real visits. That means the experience of your slower visitors on older phones and patchy connections counts, not just yours on office wifi.
Field data versus lab data
There are two kinds of numbers, and mixing them up causes a lot of confusion.
- Field data comes from real Chrome users visiting your site over the past 28 days. It's what Search Console reports and what counts. Low-traffic pages may not have enough visits to show any.
- Lab data comes from a single simulated load, such as a Lighthouse run. It's useful for finding causes and testing fixes, but the score moves between runs and doesn't measure INP directly.
Start with the Core Web Vitals report in Search Console to see which groups of pages fail, then open a failing URL in PageSpeed Insights, which shows field data on top and a lab diagnosis below.
Fixing LCP
A slow LCP is usually one of four things: a slow server response, a large hero image, render-blocking files, or content that only appears after JavaScript runs.
- Serve pages fast. Render or cache HTML on the server or at the edge instead of building it on every request, and check your time to first byte.
- Shrink the hero image. Size it for the screen, use WebP or AVIF, and don't lazy-load the image that is the LCP element.
- Tell the browser early. Preload the hero image or give it a high fetch priority so it isn't discovered late.
- Cut render-blocking work. Inline critical CSS, defer non-essential scripts and limit custom fonts to the weights you use.
- Don't hide the main content behind client-side rendering. If the headline only appears after a JavaScript bundle downloads and runs, LCP waits for all of it.
Fixing INP
Poor INP means the browser's main thread is busy when the visitor tries to do something. The usual culprits are heavy JavaScript and third-party scripts.
- Audit third-party tags: chat widgets, analytics, heatmaps, A/B testing and ad scripts. Remove what nobody looks at and load the rest after the page is interactive.
- Break up long tasks. Work that takes hundreds of milliseconds, such as filtering a big list on every keystroke, should be split, debounced or moved off the main thread.
- Show feedback immediately. Update the button or show a loading state first, then do the slow work.
- Ship less JavaScript. Remove unused libraries and load rarely used features only when needed.
Chrome's Performance panel shows long tasks and which script caused them. Field data in PageSpeed Insights tells you which interactions are slow for real users.
Fixing CLS
Layout shift is the easiest of the three to fix once you see it.
- Give every image, video and embed a width and height, or an aspect ratio, so space is reserved before it loads.
- Reserve space for banners, cookie notices and ads instead of pushing content down when they arrive.
- Load web fonts in a way that doesn't reflow text, for example with a fallback font tuned to the same size.
- Avoid inserting content above what the visitor is reading, unless they asked for it.
Check the fix in the right place
Lab tools confirm a fix straight away. Field data takes up to 28 days to fully reflect it, because it's a rolling window of real visits. In Search Console you can mark an issue as fixed to start validation, then watch the page group move from poor to good.
Not sure where your site stands? A Deeraf Tech Check measures speed, SEO and conversion on your key pages and gives you a fixed-price plan for what's worth fixing first.