Core Web Vitals are three measurements Google uses to judge whether a page feels good to use. They are a confirmed ranking signal, and more importantly they correlate strongly with whether visitors stay.
You do not need to know how to fix them. You do need to know what they mean, so you can tell whether your developer is doing the job.
The three metrics
LCP — Largest Contentful Paint
Plain English: how long until the biggest thing on screen appears. Usually your hero image or main headline.
Passing: under 2.5 seconds. Needs work: 2.5–4.0. Poor: over 4.0.
Why it matters: this is the moment a visitor thinks "the page has loaded". Before it, they are looking at nothing and deciding whether to leave.
Common causes of a bad LCP: slow hosting, an enormous unoptimised hero image, lazy-loading the hero image (a very common mistake), render-blocking CSS, fonts loading before text can display.
INP — Interaction to Next Paint
Plain English: when someone taps or clicks, how long until the page visibly responds.
Passing: under 200 milliseconds. Needs work: 200–500. Poor: over 500.
Why it matters: this is the "is it broken or just slow?" feeling — you tap a menu and nothing happens, so you tap again. INP replaced the older First Input Delay metric in March 2024 because it measures *all* interactions, not just the first one.
Common causes: too much JavaScript, heavy third-party scripts (chat widgets and analytics are frequent culprits), unoptimised event handlers.
CLS — Cumulative Layout Shift
Plain English: how much the page jumps around while loading. You go to tap a button, an ad loads above it, everything shifts, and you tap the wrong thing.
Passing: under 0.1. Needs work: 0.1–0.25. Poor: over 0.25.
Why it matters: it is the single most irritating thing a website can do, and it is almost always avoidable.
Common causes: images without width and height attributes, ads or embeds injected into the layout, web fonts swapping and changing text size, content inserted above existing content.
Of the three, CLS is usually the cheapest to fix and LCP is usually the one that needs hosting or image work. Start with CLS for a quick win, then plan properly for LCP.
Lab data vs field data — the distinction that confuses everyone
Two very different numbers get reported and people mix them up constantly.
Lab data is a simulated test run on demand — what PageSpeed Insights shows at the top. Useful for debugging, because it is repeatable.
Field data is what real visitors actually experienced over the past 28 days, collected from Chrome users. This is the Chrome UX Report, and this is what Google uses for ranking.
So your lab score can be 98 while your field data fails, or vice versa. If you fix something today, field data takes up to 28 days to reflect it. This catches people out constantly — they fix an issue, retest, see no change in field data, and conclude the fix did not work.
A page also needs enough traffic to have field data at all. Low-traffic pages fall back to origin-level data for the whole domain.
How to check your own site
- PageSpeed Insights (pagespeed.web.dev) — enter a URL. Field data at the top, lab data below. Always read the mobile tab.
- Google Search Console → Experience → Core Web Vitals — shows every URL on your site grouped into Good, Needs Improvement and Poor. This is the best view because it covers the whole site.
- Chrome DevTools → Lighthouse — for developers debugging a specific page.
Check mobile first. It is almost always worse, and it is what Google indexes with.
What to actually ask your developer
If your site is failing, these are the useful requests:
- "What is our server response time, and is the hosting the bottleneck?"
- "Is the hero image lazy-loaded? It should not be."
- "Do all images have explicit width and height attributes?"
- "Which third-party scripts are on the page, and can any be removed or deferred?"
- "Are we serving WebP or AVIF?"
- "Which pages does Search Console flag as Poor, and what is the plan for each?"
Those six questions cover the majority of real issues.
How much does this actually affect rankings?
Less than people fear, and more than they hope.
Core Web Vitals are a genuine ranking signal but a comparatively small one. A slow page with the best answer to a query will usually still outrank a fast page with a worse answer. Google has said as much repeatedly.
Where it does decide things is between closely matched competitors. If two pages are equally relevant, the faster one wins.
And the business case does not depend on rankings at all. Bounce rate rises sharply past three seconds, and conversion rate falls with every additional second of load time. Even if Core Web Vitals were worth nothing for SEO, they would still be worth fixing.
If you want the specific WordPress fixes, our WordPress speed guide covers them in order of impact.