Core Web Vitals Explained for Business Owners

Core Web Vitals are three numbers Google collects from real people using your website, describing how it felt to use. Not how it looked to a developer’s laptop on office wifi — how it felt to a customer on a phone, on cellular, tapping a button while the page was still loading.

That framing matters because most explanations of Core Web Vitals are written for developers and lose the point. For a business owner, the three metrics answer three plain questions: How long until my customer sees the thing they came for? Does the page respond when they tap? Does it hold still while they read it? Here is what each one measures, the exact thresholds Google publishes, why two of Google’s own tools disagree about your site, and what actually changes the numbers.

The three metrics and their thresholds

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element to render. On a business website that is almost always the hero image or the main headline. Google’s threshold for “good” is 2.5 seconds or less. Between 2.5 and 4 seconds needs improvement. Over 4 seconds is poor.

Interaction to Next Paint (INP) measures how quickly the page responds to interactions — taps, clicks, typing — across the entire visit, reporting close to the slowest one. Good is 200 milliseconds or less; over 500 milliseconds is poor. INP became a Core Web Vital on March 12, 2024, replacing First Input Delay, which only measured the first interaction and was easy to pass. If a guide you are reading still lists FID, it is out of date.

Cumulative Layout Shift (CLS) measures how much the page moves around while loading — the moment a button jumps down as an image loads above it, and the visitor taps the wrong thing. Good is 0.1 or less; over 0.25 is poor. CLS has no unit; it is a score of how far and how much content shifted.

The 75th percentile rule. Google grades each metric at the 75th percentile of page visits. That means a page passes only when at least three-quarters of real visits were good. Your fastest visitors don’t rescue the number; your typical-to-slow visitors decide it. Mobile and desktop are measured separately, and mobile is almost always the harder one.

All three thresholds come from Google’s web.dev documentation, which is the source to check when someone quotes different numbers.

Field data versus lab data (why your tools disagree)

This is the single most confusing thing about Core Web Vitals, and it causes real arguments between business owners and developers.

Field data is collected from real Chrome users who visit your site, aggregated over the previous 28 days. This is what appears in the Core Web Vitals report in Search Console and at the top of a PageSpeed Insights result under “Discover what your real users are experiencing.” This is what Google uses.

Lab data is a simulation: a tool loads your page once on a throttled virtual device and reports what it saw. This is the Lighthouse score — the 0 to 100 number — and the metrics beneath it. It is useful for diagnosing why a page is slow, and useless as a verdict on whether it is slow for real people.

So a page can score 95 in the lab and be “Poor” in the field, because real visitors are on older phones, on cellular, in areas with weaker coverage, hitting pages with more content than the one you tested, with a cookie banner and a chat widget that the lab test happened to load faster. When the two disagree, believe the field.

The corollary: if your site has little traffic, there may be no field data at all. Search Console will show nothing, and PageSpeed Insights will say there isn’t enough real-user data. That is not a pass; it is an absence of evidence. The lab numbers are your best guide until traffic grows.

Do Core Web Vitals affect ranking?

Yes, and less than the industry implies. Google’s page experience documentation says two things at once, and both are true: Core Web Vitals “are used by our ranking systems,” and Google “always seeks to show the most relevant content, even if the page experience is sub-par.” There is, in Google’s words, no single page-experience signal.

The practical reading: between two pages of similar relevance and depth, the one with a better experience has an edge. A fast page with nothing on it does not outrank a slow page that genuinely answers the question. If your site isn’t ranking, the cause is more likely to be content and local signals than vitals — see our four-stage ranking diagnosis.

Where vitals matter unambiguously is conversion. A visitor who waits four seconds for a hero image, taps a button that doesn’t respond, or hits the wrong link because the layout jumped is a visitor who leaves. Google’s own published case studies on web.dev document businesses seeing measurable sales increases from LCP and INP improvements. Speed is a business metric wearing a technical name; Why Fast Websites Convert Better goes into the mechanism.

What actually moves each number

Here is what we find behind poor scores on business websites, most to least common, and what fixes them. The “who fixes it” column is the honest part: some of this you can do from a dashboard, and some of it is the architecture of the site.

The pattern in the right column is the point. A caching plugin and an image-compression plugin can pull a mediocre site toward the thresholds. They cannot make a page-builder site with fifteen plugins and four tracking scripts consistently fast on a mid-range phone, because the weight is the architecture. This is why sites rebuilt on a static-first framework like Astro, served from Cloudflare’s edge, tend to pass all three vitals by default rather than after months of tuning: the pages are pre-built HTML with almost no JavaScript, images are optimized at build time, and there is no server to be slow. WordPress vs Astro for Business Websites covers when that trade-off is worth making, and when it isn’t.

How to check your own site in five minutes

1. Open PageSpeed Insights and enter your homepage and your most important service page.
2. Look at the top section first — real-user field data — not the score. If it says there isn’t enough data, note that and use the lab numbers with caution.
3. Select Mobile. Desktop almost always passes; mobile is where visitors and problems are.
4. Read the three vitals against the thresholds above.
5. If you have Search Console, open the Core Web Vitals report to see which groups of pages fail and on which metric.

If most of your pages are poor on mobile LCP, the site is heavy, and that is worth taking seriously — not because Google will punish you tomorrow, but because every visitor is already paying the cost.

What to do with the result

Good on all three: leave it alone and spend your energy on content and conversion.

Needs improvement on one: usually image weight or a single heavy script. Worth a developer afternoon.

Poor on two or three, especially on mobile: the site’s architecture is the problem, and the honest fix is usually a rebuild on a lighter foundation rather than a year of plugins. That is a bigger decision, and Signs Your Website Needs a Redesign helps make it without emotion. If you want a second opinion, speed is one of the ten categories in a free CactusScore™ roast, and we’ll tell you plainly whether it’s a tune-up or a foundation problem.