Core Web Vitals for small business websites: LCP, INP and CLS explained for agencies

Speed is the easiest website problem to prove and one of the easiest to explain badly. "Your PageSpeed score is 38" means nothing to a business owner and not much more to a developer. Core Web Vitals are better, because Google publishes exactly what they measure and where the lines are, but only if you know which numbers to trust on a small site.

The three metrics

Core Web Vitals are three measurements of what a visitor actually experiences.

Largest Contentful Paint (LCP) measures how long it takes for the largest visible element, usually a hero image or the main heading, to appear. Good is 2.5 seconds or less; poor is over 4 seconds.

Interaction to Next Paint (INP) measures how quickly the page responds when someone taps, clicks or types, across the whole visit. Good is 200 milliseconds or less; poor is over 500 milliseconds. INP replaced First Input Delay as a Core Web Vital in March 2024, and it is much harder to pass, because it looks at every interaction rather than just the first.

Cumulative Layout Shift (CLS) measures how much the page jumps around while loading: the button that moves just as you tap it. Good is 0.1 or less; poor is over 0.25.

Google assesses each metric at the 75th percentile of real page loads, so a site passes only if three out of four visits are good.

Field data versus lab data

This distinction matters more for small businesses than anyone else.

Field data comes from real Chrome users visiting the site, collected in the Chrome UX Report. It is what Google uses. But it only exists when a site has enough traffic, and many local business sites do not. For those sites, PageSpeed Insights will say there is not enough real-user data.

Lab data comes from loading the page in a controlled environment, typically a throttled mobile device on a slow connection. It is available for every site, repeatable, and good for diagnosing causes. It cannot measure INP directly, because nobody is interacting with the page, so tools report Total Blocking Time as a stand-in.

For a small business audit, the honest approach is to quote field data when it exists, say so when it does not, and use lab data to explain why the page is slow. Never present a lab number as if it were what Google sees.

What usually causes a slow small business site

In our experience, the same few causes explain most failing sites:

• Oversized images. A 3MB photo straight from a phone as the hero image. This is the most common cause of a poor LCP, and the cheapest fix.

• Page builders and heavy themes loading scripts and styles for features the page does not use.

• Third-party scripts: chat widgets, booking tools, review carousels, several analytics tags. Each one competes for the main thread and hurts INP.

• Slow hosting. A long server response time delays everything after it. If the first byte takes over a second, no front-end fix will get LCP under 2.5 seconds.

• Web fonts and images without dimensions, which cause layout shift as they load.

How to explain it to the owner

Owners do not care about milliseconds. They care about whether people leave. Translate each metric into what a customer experiences:

On a phone, your home page takes 5.4 seconds to show its main content. Google considers anything over 4 seconds poor. People searching for an emergency plumber on their phone do not wait that long; they go back and call the next result.

Then pair it with the cause and the fix: "The main photo on the page is 3.1MB. Resizing it would likely bring this under 3 seconds." A problem with a concrete, cheap fix gets approved.

If field data is not available, say so plainly, and explain that the lab test simulates a mid-range phone on a mobile connection. That is honest, and it pre-empts the owner saying the site "loads fine on my phone" on office Wi-Fi.

Does speed affect rankings?

Core Web Vitals are part of Google's page experience signals, but relevance and content quality matter far more. It is better to sell speed on conversions and customer experience than on rankings. A faster site is not guaranteed to rank higher; a slow site is guaranteed to lose some of the visitors it already has.

Measuring before and after

Whatever you fix, measure it the same way before and after, on the same device profile, and keep both results. Field data takes up to 28 days to reflect changes, so set that expectation with the client and use lab data to show immediate progress.

For the rest of the checks worth running alongside speed, see the website audit checklist, and for how to structure the report, presenting an audit to a business owner.

SiteAssay measures Core Web Vitals in a real headless browser and uses field data where Google has it, and the report says which is which. Our methodology lists the thresholds behind each check. To see where a site stands now, run a free website audit.