Somewhere in your Google Search Console there is a report called Core Web Vitals, with URLs marked “Good”, “Needs improvement” or “Poor”. If you’ve looked at it and closed it again, you’re in good company. The three metrics have unhelpful names and are explained, almost everywhere, by engineers for engineers.
Here is the business-owner version. Three numbers, what each means for a visitor, what “good” is, and what usually goes wrong.
Why these three numbers exist
Google wanted a way to measure whether a page feels fast and stable to a real person — not whether it is technically “loaded”, which can be true while the visitor is still staring at a blank screen. In 2020 it settled on three measurements, collected from real Chrome users as they browse, and in 2021 started using them as one of its ranking signals; the responsiveness metric was swapped for a stricter one (INP) in 2024. The current thresholds are published on Google’s own web.dev.
A page passes when at least 75% of its real visits meet all three thresholds. So this is not a lab test of your site on a fast office connection; it is what your actual visitors, on their actual phones, experience.
1. LCP — “How long until I see the main thing?”
Largest Contentful Paint measures the time from the visitor opening the page to the biggest element in view being drawn — usually the hero image or the headline. It’s the moment the page stops looking empty and starts looking like your website.
- Good: 2.5 seconds or less.
- Needs improvement: 2.5 to 4 seconds.
- Poor: over 4 seconds.
A visitor’s patience runs out somewhere around three seconds. LCP is the metric that decides whether they’re still there.
What usually breaks it: a hero image that’s far too large; a slow server that takes a second to even start sending the page (common on cheap WordPress hosting); fonts that must download before text appears; scripts in the head of the page that run before anything is drawn. Our three demo sites have LCP between 1.5 and 1.8 seconds on mobile; the single biggest lever on each was serving the hero image at the size the phone actually displays.
2. INP — “When I tap something, does it respond?”
Interaction to Next Paint measures how long the page takes to react when a visitor taps, clicks or types. Not whether the action completes — whether the screen visibly responds. It looks at all the interactions during a visit and reports close to the worst one.
- Good: 200 milliseconds or less.
- Needs improvement: 200 to 500 ms.
- Poor: over 500 ms.
Two hundred milliseconds is the point at which a tap stops feeling instant. Above half a second, people tap again, assume the site is broken, or leave.
What usually breaks it: JavaScript. Specifically, too much of it running on the browser’s one main thread — page-builder frameworks, animation libraries, chat widgets, analytics and advertising scripts all competing for the same lane. A visitor taps “Menu”, and the menu waits in the queue behind a tracking pixel. Pages that ship little or no JavaScript — the three demos ship none — have nothing to queue behind, and INP is a non-issue.
3. CLS — “Did the page jump around while I was reading?”
Cumulative Layout Shift measures how much things move after they’ve appeared. You’ve felt it: you go to tap a button, an image loads above it, the button moves and you tap an advert instead. CLS adds up every such jump during the visit.
- Good: 0.1 or less.
- Needs improvement: 0.1 to 0.25.
- Poor: over 0.25.
The number is a score, not a time: 0 means nothing moved. It’s the metric most directly about trust — a page that lurches feels broken, and people don’t fill in forms on sites that feel broken.
What usually breaks it: images without reserved space, so the text below jumps down when they arrive; cookie banners and notification bars that push the page down after it has loaded; fonts that swap from a fallback to the real face at a different size; adverts and embeds that expand. The fixes are mostly discipline: every image gets its width and height declared, banners overlay instead of push, fonts are sized to match their fallback. All three demos score exactly 0.
Where to see your own numbers
Two places, and it’s worth knowing the difference.
Google Search Console → Experience → Core Web Vitals. This is the field data: real visits, grouped by URL, over the last 28 days. It’s the one Google actually uses. If the report says “not enough data”, your site doesn’t yet have enough Chrome visitors to measure — common for new or small sites, and not a failure.
PageSpeed Insights (pagespeed.web.dev). Paste any address. The top section, “Discover what your real users are experiencing”, is the same field data if it exists. Below it, “Diagnose performance issues” is a lab test run right now on a simulated mid-range phone, which gives you LCP and CLS immediately plus a list of causes. The lab test is what the meter on our homepage runs as well.
Use the field data to know whether you have a problem; use the lab test to find out why.
How much it matters for ranking
Honestly: a little, not a lot. Google has said that page experience is a ranking factor but that content relevance comes first — Core Web Vitals act more like a tiebreaker between otherwise similar pages than a lever that lifts a weak page. The reason to care is the one above the ranking: these three numbers describe whether people who arrive at your site stay, tap and enquire. A page that fails them is losing visitors whether or not Google notices.
The short version
| Metric | Plain meaning | Good |
|---|---|---|
| LCP | Time until the main thing appears | ≤ 2.5 s |
| INP | Delay after a tap before the screen reacts | ≤ 200 ms |
| CLS | How much the page jumps around | ≤ 0.1 |
If your Search Console report shows red or orange, the causes are almost always in the list of seven things that make small-business sites slow — oversized images, third-party scripts, page builders, slow servers. If you’d like the three numbers for your site with the causes in plain language, that’s exactly what the free 24-hour audit is.