Skip to content
SiteFaults

What are Core Web Vitals?

The three metrics — LCP for loading, CLS for stability, INP for responsiveness — why field data is what Google scores, and how much they really matter for ranking.

By Max8 min read

Core Web Vitals are three metrics Google uses to measure the real-world experience of a page: how quickly the main content loads, how stable the layout is while it does, and how fast the page responds when someone interacts with it. They are part of how Google ranks pages — a real signal, but a light one that sits well below relevance and content quality.

The three metrics

Each vital measures a different part of the experience, and each has a “good” threshold you need to meet at the 75th percentile of your visitors.

Largest Contentful Paint (LCP) — loading. The time until the largest visible element (usually a hero image, heading, or block of text) has rendered. Good is 2.5 seconds or less.

Cumulative Layout Shift (CLS) — visual stability. How much the content jumps around as the page loads, on a unitless scale. Good is 0.1 or less.

Interaction to Next Paint (INP) — responsiveness. How quickly the page visibly reacts to taps, clicks, and key presses across the whole visit. Good is 200 milliseconds or less.

INP replaced FID in 2024

If you have read older advice, you will see First Input Delay (FID) named as the responsiveness metric. That changed: on 12 March 2024, INP replaced FID as an official Core Web Vital and FID was retired. The difference matters. FID only measured the delay before the browser started processing the first interaction, so most pages passed it easily. INP measures the full latency — input to visible response — of interactions throughout the visit, which is a far more honest picture of how responsive a page actually feels. Many sites that comfortably passed FID do not pass INP.

Field data versus lab data

This is the single most misunderstood thing about Core Web Vitals. Lab data comes from a synthetic test — Lighthouse, or our tools — run once on one device under controlled conditions. It is reproducible and great for debugging, because you can change one thing and re-measure. Field data comes from the Chrome User Experience Report (CrUX): anonymized measurements from real people on real devices and real networks, aggregated over the trailing 28 days. Google ranks on the field data. The two disagree constantly, because your real visitors are on slower phones and worse connections than a lab machine, and because CLS and INP depend on interactions a synthetic test never performs.

How much they matter for SEO

Honestly: less than most people hope. Core Web Vitals are part of Google’s page-experience signals, and page experience is a genuine but lightweight ranking factor — a tie-breaker between pages of otherwise similar relevance, not a lever that lifts weak content. Google has been explicit that great page experience will not outrank more relevant results. So the reason to fix Core Web Vitals is mostly that they measure something real: a slow, jumpy, unresponsive page loses users, conversions, and the engagement that does feed back into performance. You improve them for the visitor first and the ranking tie-breaker second.

The 75th percentile, and why one slow page-load is fine

Google assesses each metric at the 75th percentile of page loads: three-quarters of your visitors must have a good experience for the page to pass. That is deliberately forgiving of the occasional slow load and deliberately unforgiving of a problem that hits a quarter of your traffic. It also means the data is grouped — Search Console reports Core Web Vitals by group of similar pages, not URL by URL, so a fix to a shared template lifts every page built on it at once.

How to check yours

Our Core Web Vitals checker reads the field data Google actually uses, so you see your real-user LCP, CLS, and INP rather than a lab approximation. For debugging a specific fix, the page speed checker runs a Lighthouse lab test you can re-run after each change to confirm it helped. Start with the metric that is failing, follow its guide above for the usual causes, and re-measure in the field after a few weeks — the 28-day window means improvements show up gradually, not instantly. Or run a full site check to see vitals alongside the rest of your technical setup.

Frequently asked questions

What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure a page's real-world experience: Largest Contentful Paint (LCP) for loading speed, Cumulative Layout Shift (CLS) for visual stability, and Interaction to Next Paint (INP) for responsiveness. To pass, a page needs a 'good' score on all three at the 75th percentile of real visitors.
Are Core Web Vitals a Google ranking factor?
Yes, but a lightweight one. They are part of Google's page-experience signals, which act as a tie-breaker between pages of otherwise similar relevance rather than a lever that lifts weak content. Google has said great page experience will not outrank more relevant results. The stronger reason to fix them is that they measure real problems that cost you users and conversions.
What are good Core Web Vitals scores?
LCP should be 2.5 seconds or less, CLS should be 0.1 or less, and INP should be 200 milliseconds or less. Each threshold is measured at the 75th percentile of your page loads, meaning at least three-quarters of visits must hit the target for the page to be rated 'good' on that metric.
What is the difference between lab data and field data?
Lab data comes from a synthetic test like Lighthouse, run once on one device under controlled conditions — reproducible and good for debugging. Field data comes from the Chrome User Experience Report (CrUX): real measurements from real Chrome users over the trailing 28 days. Google ranks on the field data, so a page can score perfectly in the lab yet still fail its Core Web Vitals in the field.
What happened to First Input Delay (FID)?
On 12 March 2024, Interaction to Next Paint (INP) replaced First Input Delay as an official Core Web Vital, and FID was retired. FID only measured the delay before the browser began processing the first interaction, so most pages passed it easily. INP measures the full input-to-response latency of interactions throughout the visit, which is a much more honest measure of responsiveness.
How long does it take for Core Web Vitals improvements to show?
Because field data is aggregated over a trailing 28-day window, improvements appear gradually rather than immediately — you typically see the field scores move over several weeks after deploying a fix. Lab tools like Lighthouse reflect a change instantly, which is why they are the right tool for confirming a fix worked before you wait for the field data to catch up.

Run a free check on your own site

Paste any URL and get your score, your Core Web Vitals and every issue we find in about 30 seconds. No signup, no card.

Free, no signup, no card. Results in about 30 seconds, and your report is deleted automatically after 30 days.