Core Web Vitals are Google's attempt to measure something that used to be described with words like snappy or sluggish. Three numbers, each capturing a different way a page can feel wrong: it takes too long to show anything, it does not respond when you touch it, or it moves under your finger while you are reading.
They are a ranking factor, and a small one. Google has been consistent that content quality outweighs speed, and a fast page about nothing will not outrank a slow page that answers the question. That is the honest framing and it is why chasing a perfect score is usually a poor use of a week.
The reason to care is the other half. Every one of these measures a moment where a visitor might leave, and visitors who leave do not convert regardless of where you rank. Speed work pays through the funnel, not through the algorithm.
The three numbers, in plain terms
Each one has a threshold Google calls good, and each has a different usual cause.
- LCP: how long until the main thing appears?Largest Contentful Paint. Usually the hero image or headline. Good is under 2.5 seconds.
- INP: when I tap something, does it respond?Interaction to Next Paint. Measures the delay before the page reacts. Good is under 200 milliseconds.
- CLS: does the page move while I read it?Cumulative Layout Shift. The reason you tap the wrong button. Good is under 0.1.
Fixing LCP, which is usually an image
In most cases the largest element is a hero image, and in most cases it is far bigger than it needs to be. A photograph exported at three thousand pixels wide and displayed at eight hundred is a common and entirely invisible problem, because it looks correct on screen while costing several seconds on a phone.
Serve images at the size they are displayed, in a modern format, and let the browser pick between sizes rather than sending one file to every device. Then stop lazy-loading the hero. Lazy loading is right for everything below the fold and actively harmful for the one image that defines your LCP, because it delays the very thing being measured.
The other frequent cause is a font. If your text is the largest element and the font loads late, the text cannot paint until it arrives. Preloading the font file and using a fallback that displays immediately fixes a surprising number of these.
- Export images at display size, not camera size
- Use a modern format so the same picture is a smaller file
- Never lazy-load the image that is above the fold
- Preload the font your headline uses
- Check what the largest element actually is before optimising anything
Fixing INP and CLS
INP is almost always JavaScript. Something heavy is running on the main thread when the visitor taps, so the tap waits. The usual suspects are third-party scripts you added and forgot: chat widgets, heat maps, several analytics tags, an A/B testing tool. Each was justified individually and together they compete for the same thread.
Audit what actually loads. Most of it can be deferred until after the page is interactive, and a fair amount of it is measuring something nobody has looked at in a year.
CLS is the easiest to fix and the most annoying to experience. It happens because something arrives after the layout has been drawn and pushes everything down. Give images and video an explicit width and height so the browser reserves the space before the file arrives. Reserve space for banners and cookie notices rather than letting them insert themselves. And never inject content above something a person is already reading.
Measure the right thing
There are two kinds of speed data and they disagree constantly, which causes a lot of wasted argument.
Lab data comes from a tool loading your page in a controlled environment. It is repeatable and useful for testing a fix, but it is one simulated device on one connection and it is not your audience.
Field data comes from real visitors on real phones on real networks, and it is what Google uses. It lives in the Core Web Vitals report in Search Console. When lab and field disagree, field is the one that counts, and the gap is usually explained by real users being on worse connections than your test.
Start there, find which of the three you actually fail, and fix that one. Sites that fail all three are rare. Sites that spend a week optimising a metric they were already passing are not.
Common questions
- Are Core Web Vitals a ranking factor?
- Yes, but a small one. Google has been consistent that relevance and content quality outweigh page experience signals, so a fast page will not outrank a genuinely better answer. The stronger argument for fixing them is conversion: each metric marks a moment where a visitor might give up, and a visitor who leaves does not convert no matter where you ranked.
- What is a good Core Web Vitals score?
- Google's thresholds are under 2.5 seconds for Largest Contentful Paint, under 200 milliseconds for Interaction to Next Paint, and under 0.1 for Cumulative Layout Shift. You need to hit all three for a URL to pass, and the measurement uses the seventy-fifth percentile of real visits, so it reflects a slower than typical experience rather than an average one.
- Why does PageSpeed Insights disagree with Search Console?
- They measure different things. PageSpeed Insights runs a simulated load on a simulated device, which is repeatable and good for testing a change. Search Console reports what real visitors experienced on real hardware and connections. When they disagree, trust Search Console, because that is both the truth and the data Google actually uses.
- Do I need a developer to fix Core Web Vitals?
- Often not for the biggest win. Oversized images cause most Largest Contentful Paint failures and can be fixed by re-exporting and re-uploading. Removing an unused third-party script is usually a settings change. You will want a developer for font loading, deferring JavaScript, and reserving layout space in templates.
Keep reading