What are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure page experience: Largest Contentful Paint for loading, Interaction to Next Paint for responsiveness, and Cumulative Layout Shift for visual stability. Each has good, needs improvement and poor thresholds, assessed at the 75th percentile of real visits.
Formula
A page passes when the 75th percentile of real user visits is good for all three metrics
- LCP
- Largest Contentful Paint. Good under 2.5 seconds, poor above 4.0.
- INP
- Interaction to Next Paint. Good under 200 ms, poor above 500. It replaced First Input Delay in March 2024.
- CLS
- Cumulative Layout Shift. Good under 0.1, poor above 0.25. Unitless.
Worked example
One page, 30 days of field data.
| LCP at p75 | 2.1 s, good |
|---|---|
| INP at p75 | 240 ms, needs improvement |
| CLS at p75 | 0.04, good |
| LCP at p75, mobile only | 3.4 s, needs improvement |
The page fails Core Web Vitals on INP, and fails LCP on mobile alone A blended pass hides a mobile failure. Always read the three metrics split by device, because mobile is where the thresholds actually bite and where most traffic usually is.
What each metric actually measures
LCP is when the largest visible element finishes rendering, which is a proxy for when the page looks loaded to a human. It is usually a hero image, a heading or a large text block, and it is dominated by server response time, render-blocking resources and image weight.
INP measures responsiveness across the whole visit, not just the first tap. It looks at the delay between an interaction and the next frame painted, and reports a high percentile of them. Long tasks on the main thread are the usual cause, which makes it the metric most affected by heavy JavaScript.
CLS measures unexpected movement: content jumping while the page loads. Images without dimensions, ads injected above existing content, and web fonts swapping in are the standard causes, and they are all fixable with layout reservations.
Compared
The thresholds Assessed at the 75th percentile of real visits over a 28-day window, split by mobile and desktop.
| Metric | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 s or less | 2.5 s to 4.0 s | Over 4.0 s |
| INP | 200 ms or less | 200 ms to 500 ms | Over 500 ms |
| CLS | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
Thresholds as published by Google. INP replaced First Input Delay as a Core Web Vital in March 2024, which made many sites that had comfortably passed FID start failing.
Lab data and field data are not the same test
This is where most Core Web Vitals conversations go wrong.
Lab data comes from a synthetic run on a simulated device and network, which is what Lighthouse gives you. It is repeatable, it is available before you ship, and it is excellent for debugging. It is not what Google uses for assessment.
Field data comes from real visits on real devices, which is the Chrome User Experience Report and any real user monitoring you run yourself. It is what actually counts, it is noisy, and it lags by up to 28 days.
A perfect Lighthouse score with failing field data is a common and completely coherent outcome: your test machine is faster than your visitors' phones, and your test network is better than theirs. Trust the field data, and use lab data to work out why.
To see where a page currently stands on all three, the free Core Web Vitals checker reports them without a signup.
Live demo
See it on real data. The live demo is a fully populated dashboard on demo traffic, with no signup and no card.
Open the live demoThe honest position on rankings
It is a real but small signal
Page experience is a confirmed ranking factor and a weak one. It rarely outweighs relevance, and no amount of performance work will rank a page that does not answer the query.
It matters most as a tiebreaker
Between two comparably relevant results, the faster one has an edge. That is the realistic size of the effect.
The conversion effect is larger
Slow pages lose people regardless of ranking. Bounce rate and mobile conversion respond to LCP more reliably than ranking position does.
Analytics scripts are part of the problem
Every tag you add competes for the main thread and shows up in INP. A tracker measured in kilobytes rather than tens of kilobytes is the cheapest performance decision available.
Core Web Vitals in mrkr
mrkr collects LCP, INP and CLS from real visits through the browser's own performance APIs, so you get field data for your own site segmented by page and device rather than a site-wide average from an external report.
That segmentation is the part that makes it actionable. A site-level score tells you there is a problem; the same three metrics for your top ten landing pages, split by device, tells you which template to fix.
The tracker itself is under 6 kB gzipped, which keeps its own contribution to the numbers small. Measuring performance with a heavy script is a well-known way to make the thing you are measuring worse.
FAQ
Do Core Web Vitals affect SEO rankings?
Yes, as part of the page experience signals, and the effect is small. It functions mainly as a tiebreaker between pages of similar relevance. The commercial case for fixing them is usually conversion and bounce rate rather than ranking.
What replaced First Input Delay?
Interaction to Next Paint, in March 2024. INP measures responsiveness across the whole visit rather than only the first interaction, which is a much harder test, and many sites that passed FID comfortably now fail INP.
Why does my Lighthouse score not match Search Console?
They measure different things. Lighthouse is a synthetic lab run on a simulated device; Search Console reports field data from real Chrome visits at the 75th percentile over 28 days. Field data is what counts for assessment, and it will always be worse than a lab run on good hardware.
Start with one line of HTML.Your first visitors show up within a minute.