Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: how quickly the main content appears, how quickly the page responds when someone interacts with it, and how much the layout jumps around while it loads.
How Core Web Vitals work
At the time of writing (October 2026) the three metrics and Google’s thresholds for a “good” score are:
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| Largest Contentful Paint (LCP) | When the biggest image or text block in view has rendered | 2.5 seconds or less | Over 4 seconds |
| Interaction to Next Paint (INP) | How long the page takes to respond visibly to taps, clicks and key presses | 200 milliseconds or less | Over 500 milliseconds |
| Cumulative Layout Shift (CLS) | How much content moves unexpectedly | 0.1 or less | Over 0.25 |
INP replaced an older metric, First Input Delay, in March 2024, because it measures responsiveness across the whole visit rather than only the first interaction.
The scores that count are not from a test you run. Google uses field data collected from real Chrome users who have opted in, published as the Chrome UX Report. A page or group of pages passes when at least 75 per cent of visits over the previous 28 days meet the “good” threshold for all three metrics. Mobile and desktop are assessed separately, and mobile is usually the harder of the two.
Lab tools such as Lighthouse simulate a load on one device and connection. They are useful for diagnosing causes, but they can disagree with field data, and only field data feeds Google’s assessment.
Why it matters
Core Web Vitals are part of Google’s page experience signals. Google has been clear that relevance comes first: a fast page that answers the question badly will not outrank a slower one that answers it well. Where several pages are similarly useful, though, experience can tip the balance.
The bigger reason to care is your own visitors. Picture someone on a phone looking for an emergency electrician in Croydon. If the page takes five seconds to show anything, or the “Call now” button jumps just as they tap it, many will go back and choose the next result. Slow, jumpy pages lose enquiries whatever their ranking.
Common mistakes
- Chasing a Lighthouse score of 100. The lab score is a diagnostic. What matters is the field data in Search Console and PageSpeed Insights.
- Testing only the homepage. Problems are usually template-wide: every product page, every blog post. Check one URL from each template.
- Ignoring mobile. Local searches are often made on phones, and mobile scores are usually worse.
- Adding scripts without counting the cost. Chat widgets, review carousels, cookie banners and tracking tags each add work that hurts INP and LCP.
- Expecting instant results. Field data covers 28 days, so a fix takes weeks to show fully.
How to act on it
Open the Core Web Vitals report in Search Console to see which groups of URLs fail and on which metric. If your site has too little traffic for field data, use Lighthouse lab results as a guide instead. Then work by template, starting with the pages that bring in enquiries or sales.
Typical fixes include sizing and compressing the hero image and loading it early (LCP), breaking up long JavaScript tasks and removing unneeded third-party scripts (INP), and reserving space for images, ads and banners (CLS). These are often developer tasks, and prioritising them alongside crawl and indexing issues is part of my technical SEO service.