Core Web Vitals for a small business site.
Three numbers, what each one measures, why they matter less than the people selling audits claim, and the four things behind nearly every failure.
Core Web Vitals are three numbers Google publishes about how your page behaves for real visitors: how fast the main thing appears, how quickly the page reacts when somebody taps it, and how much the layout jumps around while it loads. On a small business site, four causes account for nearly every failure, and three of them are fixable in an afternoon by somebody who knows what they are doing.
That is the whole subject. What follows is the detail, including the parts the people selling you a speed audit tend to skip.
What the three numbers actually measure
Forget the acronyms for a second and think about what a visitor experiences.
Largest Contentful Paint is how long until the biggest thing on the screen shows up. On most small business sites that is the hero image or the headline at the top. It answers the question "did anything happen yet".
Interaction to Next Paint is how long the page takes to visibly respond when somebody taps or clicks. It answers "is this thing broken, or just thinking". It replaced an older measure in 2024 and it is stricter, because it looks at every interaction on the page rather than only the first one.
Cumulative Layout Shift is how much content moves around after it first appears. It answers "why did the button move just as I went to press it". This is the one that makes people close a page in annoyance without ever knowing why.
Google publishes the thresholds, so these are not opinions.
| Measure | Good | Needs work | Poor |
|---|---|---|---|
| Largest Contentful Paint | 2.5 seconds or less | 2.5 to 4 seconds | Over 4 seconds |
| Interaction to Next Paint | 200 milliseconds or less | 200 to 500 ms | Over 500 ms |
| Cumulative Layout Shift | 0.1 or less | 0.1 to 0.25 | Over 0.25 |
To pass, the great majority of your real visits have to land in the good band, measured over the previous 28 days, on real phones and real connections rather than on a clean laptop in an office.
Why they matter less than you are told
An entire industry sells speed audits on the implication that your rankings are being held back by a number in a report. That implication is mostly wrong, and it is worth saying plainly before anybody takes your money.
Google has been consistent that page experience is a small signal and that relevance comes first. A page that answers the search better will beat a faster page that answers it worse, nearly every time. If you are not ranking for "furnace repair" in your town, the cause is almost certainly that you have no page about furnace repair in that town, not that your layout shift is 0.14.
The scores also get misread constantly. The number most people quote is the green circle from a lab test, which is a simulation on a throttled connection. It is useful for diagnosis and it is not what Google uses. What Google uses is field data from real Chrome users, and a site below a traffic threshold does not have enough of it to be assessed at all. Plenty of local businesses are being sold an urgent fix for a measurement that does not yet exist for their site.
And a perfect score sells nothing. We have seen sites load in under a second and convert nobody, because the page did not say what the business did or make the next step obvious. Speed is a floor, not a strategy.
Why they matter more than you think
Now the other side, because the honest answer is not "ignore it".
These numbers are a proxy for something that genuinely costs you money: how a page feels on a six-year-old phone on mobile data in a parking lot, which is where a large share of local enquiries actually begin. A four second wait on your contact page is not a ranking problem. It is a person going back to the results and tapping the next listing.
Three practical reasons to care.
- Paid traffic makes it expensive. You pay for every click that bounces before the page renders. The arithmetic there is brutal and immediate, which is why we will not run ads to a site we know is slow.
- It is a tiebreaker. When two pages serve the search equally well, experience can decide. In a local market where three competitors all have a thin page about the same service, tiebreakers decide real money.
- It is a proxy for build quality. A site failing on all three measures is almost never failing only there. It is usually also carrying unused scripts, a page builder's overhead and a tracking setup nobody has audited since installation.
So: not the emergency it is sold as, not the irrelevance it is dismissed as. Worth fixing once, properly, and then designing out of the next build.
How to test your own site, free
Five minutes, no tools to buy, no agency required.
- Open PageSpeed Insights and enter your home page URL. Run it.
- Read the top section first. If it shows a panel of real-user data, that is the field data Google actually uses. If it says there is not enough data, you have your answer about how urgent this is.
- Read the lab score underneath as a diagnosis, not a verdict. It will list the specific images, scripts and elements causing trouble.
- Repeat on your most important page, not just the home page. For most trades that is a service page or the contact page, and it is frequently much worse than the home page because nobody ever optimized it.
- Open Search Console and find the Core Web Vitals report. It groups every page on your site by status, which tells you whether the problem is one template or everything.
Then do the test that matters most and costs nothing. Open your own site on your own phone, on mobile data, with wifi turned off, somewhere with two bars. That is the real experience, and it is usually a surprise.
The four things that cause almost every failure
In order of how often they turn out to be the culprit on a small business site.
1. Uncompressed hero images
The single most common cause of a bad Largest Contentful Paint, and the easiest to fix.
Somebody uploaded a photo straight off a camera or a stock site. It is 4,000 pixels wide and three megabytes, and it is being displayed in a space 1,200 pixels wide. The visitor downloads all three megabytes to look at a fraction of it.
The fix is to resize images to the largest size they are actually shown at, export them as WebP or AVIF, and serve smaller versions to phones. A hero image should be well under 200 kilobytes and usually under 100. Also make sure the hero is not loading lazily, because the one image you want immediately is the one lazy loading delays.
2. Too many third-party scripts
Every tracking pixel, chat widget, review carousel, booking embed, font service and consent banner is code loaded from somebody else's server. Your page now waits on a server you do not control.
The usual pattern is accumulation. Four pixels from campaigns that ended, a chat widget nobody answers, two analytics tools measuring the same thing, and a social feed embed that pulls in more code than the rest of the page combined.
Open the network tab in your browser and count what loads. Then remove what you are not actively using. This single pass is frequently the largest improvement available, and it costs nothing but attention.
3. Page builders
Drag-and-drop builders are the reason a five-section page ships with a megabyte of stylesheets and several hundred kilobytes of JavaScript, most of it for features the page does not use.
You can mitigate this. Caching, deferring, trimming unused code and dropping add-ons all help. What you cannot do is get a builder-based page to the level of a hand-built one, because the overhead is structural rather than accidental. If the site is otherwise serving you well, mitigate. If you are about to rebuild anyway, this is one of the reasons the build method is worth asking about, which is question eleven in how to pick a web designer.
4. Images and embeds with no dimensions
This is the whole of Cumulative Layout Shift for most sites, and it is the cheapest fix on the list.
When an image has no declared width and height, the browser does not know how much room to leave. It lays out the text, then the image arrives and shoves everything down. The same happens with ad slots, embedded maps and anything injected after load.
Declare width and height on every image, reserve space for embeds, and load custom fonts in a way that does not reflow the text when they arrive. Done properly, layout shift goes to near zero and stays there.
What to fix first
If you have an hour, compress the images on your three most-visited pages and add dimensions to all of them. That single hour resolves most failures we see.
If you have a day, audit every third-party script and delete what is not earning its place, then re-test on a phone on mobile data.
If the site is on a builder and failing everywhere, stop spending on patches. You are maintaining a structural problem, and the money is better put toward a rebuild where performance is a budget enforced during the build rather than a cleanup afterwards. That is also the moment to deal with it, not before, and the sequencing is the same as for moving off a closed platform.
What to ignore: chasing a perfect hundred, buying a monthly speed-monitoring subscription, and any audit that leads with the lab score while never mentioning whether you have field data at all.
Our own home page measures itself in your browser while you read it, which is as close to showing our working as we can get. If you want the same numbers for your site and a plain answer about whether they are worth fixing, send us the URL.
Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less. Google assesses those across real visits over the previous 28 days rather than from any single test.
A little. Google has been consistent that page experience is a small signal and that relevance comes first. If you are not ranking for a service in your town, the cause is usually having no page about it rather than your layout shifting.
Run PageSpeed Insights on your most important page rather than only the home page, and read the real-user panel before the lab score. Then open the Core Web Vitals report in Search Console. Then open your own site on a phone using mobile data.
Four things, nearly always. Hero images uploaded at full camera size, a stack of third-party scripts left over from campaigns that ended, a page builder shipping code the page never uses, and images with no declared width and height.
Not on its own. If the site otherwise serves you, compress the images, declare dimensions and delete unused scripts. If it sits on a page builder and fails everywhere, stop paying for patches and put the money toward a rebuild instead.