Core Web Vitals are three measurements Google uses to judge how a page feels to a real visitor: how fast the main content shows up, how quickly the page reacts to a tap, and whether the layout jumps around while it loads. For a small business website they matter for two reasons. Google says they line up with what its ranking systems reward, and your customers feel them every time they tap your result on a phone. Here's what each one means, what counts as good, and what usually drags a local business site down.
What are Core Web Vitals?
Core Web Vitals are Google's three user-experience metrics: Largest Contentful Paint (loading), Interaction to Next Paint (responsiveness) and Cumulative Layout Shift (visual stability). A page passes when LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less, measured at the 75th percentile of real visits.
That last part matters. Google doesn't judge your site by its best load on your office Wi-Fi. It looks at the 75th percentile across real visits, mobile and desktop counted separately, so the slow phone on a weak signal counts too.
The three numbers, one at a time
LCP: how long until the main thing shows up
Largest Contentful Paint measures when the biggest piece of content in view, usually the hero photo or the headline, finishes appearing. Good is 2.5 seconds or less.
Picture it from the customer's side. They tap your result. White screen. A logo. Still no headline. Somewhere around the third second they decide your competitor's page loaded faster, and they're right, because they're already on it.
The usual culprits are a huge hero photo uploaded straight from a camera, a slider that loads five images to show one, and web fonts pulled from another server before any text can appear.
INP: how quickly the page reacts
Interaction to Next Paint measures the delay between a tap or click and the page visibly responding. Good is 200 milliseconds or less. It replaced an older metric, First Input Delay, in 2024, so guides that still talk about FID are out of date.
A slow INP feels like a menu that opens a beat late, or a "Get a quote" button that does nothing for a moment, so the visitor taps it again. It's almost always caused by too much JavaScript running at once: chat widgets, tracking scripts, page-builder code and animation libraries all competing for the same phone processor.
CLS: whether the page jumps
Cumulative Layout Shift measures how much things move around while the page loads. Good is 0.1 or less.
You've felt this one. You go to tap a button, an image finishes loading above it, everything shifts down, and you tap an ad or the wrong link instead. On a service site that might be the phone number moving just as someone reaches for it. The fix is usually simple: give every image and embed a fixed size, so the browser saves the space before it arrives.
Are Core Web Vitals a ranking factor?
Partly, and it's easy to overstate. Google's own Search documentation says it "highly recommends" achieving good Core Web Vitals and that they align with what its core ranking systems seek to reward. It doesn't say they outweigh relevance. A fast page about the wrong thing won't outrank a slower page that answers the search.
Our honest view: treat speed as a customer problem first and a ranking problem second. The ranking benefit is real but modest. The customers you lose to a slow page on a phone are lost either way.
How to check your Core Web Vitals
Two free tools, both from Google:
- [PageSpeed Insights](https://pagespeed.web.dev/). Paste in any URL. The top section, "Discover what your real users are experiencing", is field data from real Chrome users, if your site gets enough traffic to have it. The section below it is a lab test, Lighthouse, run on a simulated phone.
- Google Search Console. The Core Web Vitals report groups your pages into good, needs improvement and poor, based on real visits.
Know which one you're looking at. Field data is what Google uses, and it's based on the last 28 days, so a fix won't show up there straight away. Lab data is a single simulated load, useful for finding the cause but not the final verdict. Small local sites often don't have enough visits for field data at all, and then the lab test is the best guide you have.
A real measurement, including the part that isn't perfect
Here's a site we built and measured, with nothing tidied up.
Molino Pest Control is a pest control company in Tanauan City, Batangas. Until this site, its only presence online was a Facebook page, and having a real website of its own is what made the business look legitimate to customers who had never heard of it. We measured the live homepage on 12 October 2026. From a home fibre connection nearby, the page's HTML arrived in 0.17 seconds. Google's Lighthouse on its mobile profile scored it 100 for SEO, 100 for best practices and 96 for accessibility, with zero layout shift and zero blocking time.
The performance score was 81. What held it back was the hero: a carousel of the client's own job photos. We could have swapped it for one compressed image and chased a higher score. We didn't, because real photos of the technicians at work do more to win a pest control job than a few extra points on a lab test. A good score is a means to an end. The end is a page that loads quickly enough and makes someone pick up the phone.
And the 81 hasn't held it back. The site went live on 9 October 2026, and within its first week Google Search Console showed an average position of 6.6 across the searches it appeared in. Speed got it in the door. Relevance, clean headings and schema markup did the rest.
That's the kind of trade-off you should expect a web team to explain to you, not hide.
Why small business sites usually fail
When we audit a slow local business site, it's rarely one dramatic problem. It's an accumulation:
- Page builders and stacked plugins. Each one adds its own scripts and styles to every page, whether that page uses them or not.
- Photos straight off the camera. A 5 MB hero image on a phone screen that's 400 pixels wide.
- Third-party scripts. Chat bubbles, review widgets, tag managers, ad pixels and heat maps. Each is small. Together they can cap your mobile score no matter how well the rest of the site is built.
- Cheap shared hosting far from your customers. If the server is on another continent, every visit waits for the round trip.
How to pass without heroics
You don't need tricks. You need to not ship the bloat in the first place.
- Resize and compress every image to the size it's actually shown, in a modern format.
- Give images and embeds fixed dimensions so nothing jumps.
- Host your fonts on your own site and load only the weights you use.
- Audit your third-party scripts. Keep the ones that earn their keep. Remove the rest.
- Serve the site from a network with locations near your customers.
On the sites we build, pages are rendered ahead of time and delivered finished, so the phone isn't left assembling them, and they're served from Vercel's edge network, so the nearest copy sits close to whoever is visiting. That's most of the work done before anyone starts optimising.
What's a good PageSpeed score for a small business?
Aim for the three Core Web Vitals in the green first, because those are what Google actually reports on. The overall Lighthouse performance score is a lab summary and swings from run to run. A site in the 80s with passing vitals and real photos is in better shape than one in the high 90s that's a blank template.
Why is my website slow on mobile but fine on my computer?
Because your computer has a fast processor and a fast connection, and your customer's phone may have neither. PageSpeed Insights tests mobile on purpose, with a slowed-down processor and network. If your mobile score is far below desktop, the cause is usually JavaScript and image weight, which a phone feels far more than a laptop does.
If your mobile numbers are in the red, that's jobs going to faster competitors. A site built for speed and hosting that keeps it fast is how we fix it, and it's part of what we check first when we audit any site.
