Core Web Vitals explained in plain English for small business owners
A plain-English walk-through of the three Core Web Vitals — LCP, CLS and INP — what each means for a real visitor, what counts as good, and the handful of fixes that move them.
Core Web Vitals are the three metrics Google uses to score how your pages feel to a real visitor, and they feed into search ranking:
- Largest Contentful Paint (LCP) — how fast the main content loads; good is under 2.5 seconds.
- Cumulative Layout Shift (CLS) — how much the page jumps as it loads; good is under 0.1.
- Interaction to Next Paint (INP) — how quickly it responds to a tap; good is under 200 milliseconds.
Each is measured on your real visitors, so you have to clear the bar for at least 3 in 4 of them. Check your own scores free in Google PageSpeed Insights, then fix the worst of the three first.
Core Web Vitals are the three measurements Google uses to score how your website actually feels to a real visitor: how fast the main content loads (Largest Contentful Paint), how steady the page stays as it loads (Cumulative Layout Shift), and how quickly it responds when someone taps or clicks (Interaction to Next Paint). Google's published targets are an LCP under 2.5 seconds, a CLS under 0.1, and an INP under 200 milliseconds — and crucially, you have to hit each one for at least 3 in 4 of your real visitors, not just on a one-off test from your office. They matter for two reasons: they feed into Google's search ranking, and they map directly onto whether visitors stick around or give up. You can check your own scores free in Google PageSpeed Insights. This guide walks through what each one means for a real person landing on your site, and the short list of fixes that actually move them.
The three metrics, in the order a visitor experiences them
Think about what happens when someone taps a link to your site. First they wait for something to appear. Then they watch the page fill in — hopefully without it jumping around. Then they try to use it, and either it responds or it doesn't. Each Core Web Vital measures one of those three moments.
Largest Contentful Paint (LCP) — "has the page loaded yet?"
LCP measures how long it takes for the biggest visible thing on your page to finish loading. On most small-business sites that is the hero image at the top, or a large headline. It is the closest single number to the question every visitor is silently asking in the first couple of seconds: is this page ready, or is it broken?
- Good: under 2.5 seconds
- Needs improvement: 2.5 to 4 seconds
- Poor: over 4 seconds
LCP is the metric most small-business sites fail, and the cause is almost always the same: one oversized image. A photo straight off a phone or a stock-library download can be several megabytes and thousands of pixels wide, shown in a slot a few hundred pixels across. The browser downloads the whole enormous file, then shrinks it on screen — and your visitor waits through all of it.
Cumulative Layout Shift (CLS) — "why did the page just jump?"
CLS measures how much your page visually moves around while it loads. You know the experience: you go to tap a button, an image finishes loading above it, everything lurches down, and you tap an ad or the wrong link instead. That jump is layout shift, and Google scores it.
- Good: under 0.1
- Needs improvement: 0.1 to 0.25
- Poor: over 0.25
The usual cause is images, ads or embeds that arrive without the browser knowing how much space to leave for them. Until the image loads, the browser does not know it is 400 pixels tall, so it leaves no gap — then shoves everything below it down when the image appears. Late-loading web fonts and injected banners (think cookie notices that drop in after the page has drawn) do the same thing.
Interaction to Next Paint (INP) — "why isn't this responding?"
INP measures how quickly your page reacts when someone interacts with it — taps a menu, clicks "add to cart", types into a search box. Specifically, it is the time between the action and the screen visibly responding. A page can load fast and still feel broken if it freezes for half a second every time you touch it.
- Good: under 200 milliseconds
- Needs improvement: 200 to 500 milliseconds
- Poor: over 500 milliseconds
INP measures interactions across the whole visit, not just the first one, so a site that responds well on load but stutters as you use it still scores badly. The cause is almost always too much JavaScript — scripts running on the browser's main thread, blocking it from reacting to taps. On small-business sites the worst offenders are usually third-party: chat widgets, tag managers, tracking pixels.
Lab data vs field data — and why your scores can disagree
When you run PageSpeed Insights, you will see two sets of numbers, and it is worth understanding why they can tell different stories.
Field data is collected from your actual visitors over the past 28 days, on their real phones and real connections, through the Chrome User Experience Report. This is the data Google uses for ranking. It is the truth about your customers.
Lab data is a single test run right now, in a controlled environment on a simulated device. It is repeatable and brilliant for debugging — you can change something and immediately see if it helped — but it is one synthetic visit, not your audience.
The two can disagree. A common pattern is a healthy lab score but poor field data, which almost always means your real visitors are on slower phones and patchier networks than the lab assumed. When they disagree, trust the field data: those are the people actually using your site. If your site is quiet enough that Google has no field data to show, work from the lab data and fix the obvious things — the real-world numbers will follow once there are enough visitors to measure.
One note many owners miss: your mobile score will usually be much worse than desktop, and that is by design. PageSpeed Insights tests mobile on a deliberately modest phone and a throttled connection, because that is how most people browse. The mobile column is the one to take seriously — Google ranks mobile-first, and it is where most of your visitors and most of your problems live.
The handful of fixes that actually move the needle
You do not need to chase a perfect 100. You need to get all three vitals into the green on mobile, and a short list of fixes does most of that work.
Fix the hero image (moves LCP)
This is the highest-impact change on most sites. Resize your hero image to roughly the size it actually displays, save it as WebP (typically 25 to 35% smaller than JPEG at the same quality, and supported in every current browser), and make sure it loads eagerly — never lazy-load the image at the top of the page, because that is your LCP element. Sort out the hero image and you have usually sorted out LCP.
Put dimensions on every image (moves CLS)
Add an explicit width and height to every image, or set them in your page builder. This tells the browser exactly how much space to reserve before the image arrives, so nothing jumps. It is two attributes on an image tag and it is the cheapest Core Web Vitals win there is. While you are at it, reserve space for anything that loads late — ad slots, embeds, cookie banners.
Cut the heavy scripts (moves INP)
Go through your third-party scripts and remove anything you are not actively using. An old chat widget you switched off, a tracking pixel for a campaign that ended, three analytics tools doing the same job — each one is code running on your visitor's phone and dragging your INP down. For the scripts you genuinely need, ask your developer to defer them so they load after the page is usable rather than blocking it.
Help the rest along
Two server-side settings round it out, and both are usually a simple toggle on your host or CDN: enable text compression (gzip or Brotli) so pages download as fewer bytes, and set a long cache policy on static files so returning visitors are not re-downloading your logo every time. A free-tier CDN like Cloudflare bundles both, plus brings your files physically closer to visitors around the country.
Where to start
Run PageSpeed Insights on your homepage and your single busiest page — for many businesses that is a product or services page, not the home page. Read the mobile column. Work down the prioritised list of opportunities it gives you; it is specific, and it puts the biggest wins at the top. Fix the top two or three, re-test, and repeat. That loop covers the vast majority of what matters, and most small-business sites only have a few real problems standing between them and three green scores.
For more background on any individual warning you run into, Google's own web.dev guides explain each one in plain terms — and our Improve hub collects plain-English answers to the questions that come up along the way. If you would rather just see the specific issues on your own site, the short, free questions library is a good next stop.