Core Web Vitals are three measurements Google takes of how your site behaves for real visitors: how fast the main content appears, how quickly the page responds when someone taps it, and whether things move around while it is loading.
Most explanations of them are written for developers. This one is written for the person paying for the work, because the useful question is not “what is LCP” but “is this costing me customers, and is it worth fixing.”
The three metrics, in plain terms
| Metric | What it measures | Good | What a bad score feels like |
|---|---|---|---|
| LCP Largest Contentful Paint |
When the main content becomes visible | Under 2.5s | Staring at a blank or half-built page |
| INP Interaction to Next Paint |
How fast the page reacts to a tap or click | Under 200ms | Tapping a button and wondering if it registered |
| CLS Cumulative Layout Shift |
How much content jumps while loading | Under 0.1 | Going to tap a link and hitting an ad instead |
You have experienced all three. CLS is the one everybody recognises immediately once it is named.
Field data versus lab data — and why your report disagrees with itself
This confuses almost every business owner who runs a speed test, so it is worth being clear.
Lab data is a simulated test run on demand. It is what most speed tools show. It is repeatable and useful for debugging.
Field data comes from actual Chrome users visiting your site over the previous 28 days. This is what Google uses.
Two consequences follow. First, a site can score well in a lab test and still fail Core Web Vitals, because your real visitors are on mid-range Android phones on mobile data, not on a fast test machine. Second, a new or low-traffic site may have no field data at all, which is not a failure — there simply is not enough data yet.
If you are being sold urgent Core Web Vitals work on a site with no field data, ask what evidence the recommendation is based on.
How much does this actually affect rankings?
Honestly: less than the people selling speed optimisation imply, and more than nothing.
Core Web Vitals are a genuine ranking signal, but a weak one compared with relevance and content quality. A faster page does not outrank a more relevant one. Where speed decides things is between pages of comparable quality — and in competitive markets, that is a lot of searches.
The stronger argument is commercial rather than algorithmic. A visitor who waits eight seconds on mobile data often does not wait. That is a conversion problem you can see in your analytics, independent of ranking.
So: fix speed because slow pages lose customers. Treat the ranking benefit as a bonus.
What usually causes each failure
Slow LCP
Almost always one of four things: a slow server response, an oversized hero image, render-blocking CSS or JavaScript, or fonts that delay text appearing.
Check server response time first. If your time to first byte is measured in seconds, nothing you do to images will help — the page has not started arriving yet. We have seen a site where every page took over ten seconds to respond, and no amount of image optimisation would have touched it, because the delay was server-side and had nothing to do with the front end.
Poor INP
Too much JavaScript competing for the browser’s attention. Common on sites carrying a page builder plus a dozen plugins, each adding scripts that run on every page whether needed or not.
High CLS
The easiest to fix and the most annoying to users. Nearly always images or embeds without declared dimensions, so the browser does not reserve space and everything jumps when they load. Web fonts swapping in at a different size do it too.
What to do, in order of value
- Measure the field data. Search Console’s Core Web Vitals report, not a one-off lab test. Know what real visitors experience before spending anything.
- Fix server response time if it is slow. Better hosting, caching, or removing whatever is blocking the request. Biggest single lever, most often ignored.
- Size and compress images properly. Serve modern formats, set explicit width and height. Fixes a chunk of LCP and most of CLS at once.
- Remove what you are not using. Every plugin, font weight and script you dropped months ago but never deleted.
- Defer non-essential JavaScript so it stops competing with rendering.
- Re-measure after 28 days, because field data lags. Do not judge the work the next morning.
When it is not worth paying for
Some blunt guidance, since this is an area with a lot of upselling.
If your site already passes, stop. There is no ranking bonus for being twice as fast as the threshold. Spend the money on content.
If you get very little search traffic, speed is not your problem. A fast site nobody finds is still a site nobody finds. Fix visibility first — see why isn’t my website showing on Google.
If the site is fundamentally unmaintainable, optimisation is a patch on a structural problem. At some point the honest answer is a rebuild rather than another round of tuning — seven signs your website needs rebuilding covers how to tell.
If someone quotes speed work without showing you the field data first, ask why.
Frequently asked questions
Do Core Web Vitals really affect Google rankings?
Yes, as part of page experience signals, but the effect is modest. They tend to matter as a tiebreaker between similarly relevant pages rather than as a way to leapfrog better content.
Why does my PageSpeed score say 95 but Search Console says I am failing?
Because they measure different things. The 95 is a lab simulation; Search Console reports what real visitors experienced over 28 days. Trust the field data — it is what Google uses.
My site has no Core Web Vitals data. Is that bad?
No. It means Chrome has not collected enough visits to report on. Common for new or low-traffic sites. Use lab testing to catch obvious problems and revisit once you have traffic.
Will a caching plugin fix everything?
It will usually help LCP by serving pages faster, and it will do nothing for CLS or INP, which are front-end problems. Caching is one tool, not the answer.
How long until improvements show in Search Console?
The report uses a rolling 28-day window, so allow a full month after the fix before judging it. Lab tests confirm the change immediately; the official verdict takes weeks.
Is mobile or desktop more important?
Mobile, clearly. Google evaluates the mobile experience, and in Nepal the majority of visitors arrive on mid-range phones over mobile data. Test in those conditions rather than on office wifi.
A sensible starting point
Open Search Console, find the Core Web Vitals report, and look at the mobile tab. If you are passing, spend your budget elsewhere. If you are failing, check server response time before anything else — it is the most common cause and the one most likely to be misdiagnosed as a front-end problem.
If you want the diagnosis done properly, our SEO services begin with a technical audit that measures this directly, and what a technical SEO audit actually finds shows the kind of issues that surface.
