SEO Guide
Core Web Vitals, Explained Without the Jargon
What LCP, INP and CLS measure, the thresholds you need to hit, why your score differs between tools, and how much any of it changes your rankings.
360 Digital Promotions 6 min read
Core Web Vitals are three measurements Google takes of what it is like to use your page. Not how fast the server responds, not how many kilobytes it weighs — what a person experiences while waiting for it, tapping on it, and reading it.
The acronyms make it sound harder than it is. Each one corresponds to a frustration you have felt on someone else’s website.
The three measurements
LCP — Largest Contentful Paint. How long before the biggest thing on screen appears. Usually the hero image or the headline. This is the “is this page loading or is my connection broken” moment, and it is measured to the point where the main content is visible, not where the last tracking script finishes.
INP — Interaction to Next Paint. You tap a button and nothing visibly happens for a beat. INP measures the delay between an interaction and the screen updating in response, across the whole visit, and reports roughly the worst of them. It replaced First Input Delay as an official Core Web Vital in March 2024, and it is harder to pass because FID only measured the first interaction while INP measures all of them.
CLS — Cumulative Layout Shift. You go to tap a link and the page jumps, so you tap an advert instead. CLS scores how much the layout moves around after it first appears. It is not measured in seconds — it is a unitless score combining how much of the screen moved and how far.
The thresholds
Google publishes specific numbers, and they are worth knowing exactly:
| Metric | Good | Poor |
|---|---|---|
| LCP | 2.5 seconds or less | over 4 seconds |
| INP | 200 milliseconds or less | over 500 milliseconds |
| CLS | 0.1 or less | over 0.25 |
Anything between the two columns sits in the needs-improvement band.
Two details people miss. First, the assessment is taken at the 75th percentile of real visits, not the average — so a quarter of your visitors can have a worse experience and you still pass. That is deliberate, and it means one slow page on an old phone will not sink you. Second, a page passes the overall assessment only when all three metrics are in the good band. Two out of three is a fail.
Why every tool gives you a different number
This is the source of most confusion, and it has one explanation: there are two kinds of data and the tools mix them.
Field data comes from the Chrome User Experience Report — anonymised measurements from real Chrome users who visited your site, aggregated over a rolling 28-day window. This is what Google uses. It is real, it is slow to move, and it needs enough traffic to exist at all. Low-traffic sites often have no field data, in which case Google falls back to origin-level data or nothing.
Lab data comes from Lighthouse running a simulated page load on a throttled connection. It is instant, repeatable, and produces the big coloured score out of 100 that everyone screenshots. That score is a diagnostic tool. It is not what Google assesses you on.
So: PageSpeed Insights shows both — field data at the top, lab below. Search Console’s Core Web Vitals report shows field data only, grouped by URL type, which makes it the right place to look for a verdict. Lighthouse in Chrome DevTools shows lab data only. A site can score 62 in Lighthouse and pass Core Web Vitals comfortably, because real visitors have better devices than the throttled simulation.
The lag matters too. Because the field window is 28 days, a fix deployed today will not show fully in Search Console for about a month. Do not deploy a change on Monday and conclude it failed on Wednesday.
What usually causes each failure
Patterns that come up repeatedly on small business sites:
Poor LCP is almost always an image. An uncompressed hero photo, served at full desktop resolution to a phone, in a format from 2003. Convert to WebP, size it for the device, and stop lazy-loading the one image that appears at the top of the page — lazy loading the LCP element delays it by definition. After images, the next culprits are render-blocking fonts and a slow server response.
Poor INP is JavaScript. Something is occupying the main thread when the user taps. On most small sites this is not custom code, it is accumulated plugins, chat widgets, heat-mapping, consent managers and a tag manager container that has grown for years. The most effective fix is usually deletion: audit what is loading and remove what nobody looks at.
Poor CLS is missing dimensions. An image without width and height attributes, so the browser does not reserve space and everything below jumps when it arrives. Web fonts that swap and reflow the text. Cookie banners and promotional bars injected above existing content. All three are fixable without rebuilding anything.
How much does this affect rankings
Less than the amount of attention it receives.
Google has been consistent that page experience signals are real but comparatively light, and that relevance wins. A slow page that answers the question will outrank a fast page that does not. If you are on page four, Core Web Vitals is not why.
Where it does matter is between comparable pages. If two results are similarly relevant, the experience signals can separate them. And there is the effect that has nothing to do with rankings: people leave slow pages. A visitor who abandons a page before it renders costs you the enquiry regardless of what position you achieved to get them there.
That is the honest framing. Treat Core Web Vitals as a conversion problem that also happens to carry a small ranking benefit, and you will prioritise it correctly.
Where to start
- Open the Core Web Vitals report in Search Console. Look at the mobile tab. If there are no URLs flagged as poor, you have a smaller problem than you think.
- Take one flagged URL group and run it through PageSpeed Insights. Read the field data section.
- Fix the images first. On most small sites this alone moves LCP into the good band.
- Audit third-party scripts second. Remove rather than optimise.
- Add width and height attributes to images and reserve space for anything injected late.
- Wait a month before judging the result.
If the answer turns out to be that the site is built on something that cannot be made fast, that is a rebuild conversation rather than a tuning one, and it is worth having honestly. That sits with website development rather than SEO.