Core Web Vitals are the three metrics Google uses to describe how a page feels to a real visitor: how fast the main content appears, how quickly the page reacts to a tap or click, and how much the layout jumps around. Google’s documentation says it highly recommends good Core Web Vitals for success with Search, and that they fit with what its core ranking systems seek to reward.
What are the three Core Web Vitals?
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the biggest visible element, a hero image or headline, has rendered | 2.5 s or less | up to 4 s | over 4 s |
| INP (Interaction to Next Paint) | How long the page takes to show a visual response after clicks, taps and keystrokes, across the whole visit | 200 ms or less | up to 500 ms | over 500 ms |
| CLS (Cumulative Layout Shift) | How much visible content moves unexpectedly | 0.1 or less | up to 0.25 | over 0.25 |
A page passes when all three meet the “good” mark at the 75th percentile of page loads, checked separately for mobile and desktop. That means three out of four real visits must be at least that good.
INP replaced First Input Delay (FID) on 12 March 2024. According to web.dev, all three metrics are stable, and their definitions change at most once a year.
Why do Core Web Vitals matter for SEO?
Google lists them as part of page experience, next to HTTPS and not covering the page with pop-ups. Relevance still wins: a slow page with the best answer can outrank a fast page with a weak one. Where two pages answer the query equally well, the faster and steadier one has the edge.
The bigger payoff sits with your visitors. A hero image that takes five seconds, a button that does nothing for half a second and an ad that shoves the text down as you read all lose sign-ups and sales, whatever Google does with the score.
Field data or lab data: which one counts?
Field data comes from real Chrome users and is collected in the Chrome UX Report (CrUX). This is what Google’s Search Console report and the top block of PageSpeed Insights show. Lab data comes from a simulated test, such as the Lighthouse run in the lower part of PageSpeed Insights.
web.dev says only field measurement captures the complete picture. Lighthouse covers LCP and CLS but not INP, because it has no real user input. It reports Total Blocking Time as a lab stand-in. So a lab score of 100 does not mean your Core Web Vitals pass, and a lab score of 60 does not mean they fail. Check the field data first.
How do you improve Core Web Vitals, step by step?
- Find the failing URLs. Open the Core Web Vitals report in Google Search Console. It groups URLs that share the same problem, for mobile and desktop. Pick the group with the most pages.
- Test one example page in PageSpeed Insights. Read the field block (labelled “Discover what your real users are experiencing”) for the metric that fails, then the diagnostics below it for the cause.
- Fix LCP. Find the LCP element in PageSpeed Insights or the DevTools Performance panel. If it is an image, compress it and serve a modern format (see image file size), add
fetchpriority="high"to it and never lazy-load it. Cut server response time with caching or a CDN, and remove render-blocking CSS and scripts from the head. - Fix CLS. Put
widthandheightattributes on every image and video so the browser reserves the space. Reserve a fixed slot for ads, embeds and cookie banners. Load web fonts withfont-display: swapand a similar fallback font. Never insert content above what the visitor is already reading. - Fix INP. Use field data to find the slow interaction, then reproduce it in DevTools. Break long JavaScript tasks into smaller pieces, delay third-party scripts such as chat widgets and tag managers until after the first interaction, and keep the DOM small. Heavy front-end frameworks need extra care: see JavaScript SEO.
- Ship the fix and wait. CrUX data is a trailing 28-day window, so Search Console needs several weeks to show a pass. Use the “Validate fix” button in the report to start tracking.
- Guard against regressions. Add Lighthouse or PageSpeed Insights checks to your release routine, and run them again after every new plugin, ad slot or script.
How do you measure the result?
- Search Console Core Web Vitals report: count of URLs rated Good, Needs improvement and Poor. This is the report to watch.
- PageSpeed Insights: field data for one URL or the whole origin, plus lab diagnostics.
- web-vitals library: a small script that sends LCP, INP and CLS of your own visitors to your analytics, so you see results the same day instead of waiting for CrUX.
- Business numbers: bounce rate and conversion rate on the pages you fixed. If a pass in Search Console does not move them, the page had other problems.
For a site-wide view of problems beyond speed, run a site audit.
What mistakes should you avoid?
- Chasing a 100 in Lighthouse. The lab score is a diagnostic. The pass or fail verdict comes from field data at the 75th percentile.
- Lazy-loading the hero image. It delays LCP on the very element that defines it.
- Ignoring INP. Many sites that fixed FID still fail INP, because INP counts every interaction, not just the first one.
- Fixing one URL and calling it done. Search Console groups similar pages. A template fix repairs hundreds of URLs at once, a one-off patch repairs one.
- Adding pop-ups and ad slots without reserved space. They create layout shifts. Google also treats some interstitials as a problem of their own (see intrusive interstitials).
- Expecting a ranking jump. Google gives no weight figure for the metrics. Treat a pass as removing a handicap.
Where can you learn more?
The Fe/male Switch landing page analyzer checks title, on-page elements and speed of a page in one pass, a quick first look before you open PageSpeed Insights. Next steps on SEO100: work through the wider page speed checklist, then compress your images.