Core Web Vitals for Small Business: Lab Scores vs Real Data

The email that arrives with a red number

It usually shows up as a screenshot. Somebody ran your website through a free speed tool, got a number in the forties, colored it red, and attached it to a message about how this is costing you customers and rankings. There is a package price at the bottom.

The number is usually real. The conclusion drawn from it is usually wrong, and the gap between those two things is where a lot of small business money goes.

The person sending it is not lying. They ran a real test and got a real result. They just did not mention that the test measures something different from what Google uses, and that on most small business sites, the thing Google uses does not exist yet.

The same page, two scores, ninety seconds apart

On August 24, 2026 I ran our own homepage through Google's PageSpeed Insights twice, changing nothing but the device setting.

Mobile scored 73, with Largest Contentful Paint at 6.5 seconds. Desktop scored 99, with Largest Contentful Paint at 0.8 seconds. Same page, same server, same minute. The mobile run flags a metric more than eight times slower than the desktop run.

Neither number is a lie, and neither is a measurement of what your visitors experienced. Both are simulations. The mobile test applies heavy artificial throttling to model a mid range phone on a slow connection, because that is a defensible way to compare pages under identical conditions. It is a laboratory. It is not your customers.

You can reproduce this in four minutes. Run the test, flip to desktop, run it again. Then ask whoever sent the red screenshot which one they ran.

What Google actually uses

Google is unusually direct about this, and the documentation is public.

The Core Web Vitals report in Search Console, the one tied to how your pages are actually evaluated, runs on field data. Google's own support documentation states that the data comes from the Chrome User Experience Report and gathers anonymized metrics from actual users visiting your URL. It does not run on Lighthouse scores. The documentation points you to PageSpeed Insights and Lighthouse as separate diagnostic tools, which is exactly what they are.

Two entirely different things share a vocabulary here. Field data records what happened to real people in Chrome over a rolling 28 day window. Lab data is a simulation run on demand against a throttled virtual device. PageSpeed Insights shows both when both exist, and most people screenshot the wrong half.

Most small business sites are not in the dataset

This is the part almost nobody tells owners, and it changes the entire calculation.

To appear in the Chrome User Experience Report, a page or origin has to clear a popularity threshold. Google's CrUX methodology documentation says a page qualifies only if it has a minimum number of visitors, that the exact figure is not disclosed, and that pages and origins below the threshold are not included in the dataset.

When I queried the CrUX API for our own domain the same afternoon I ran those two tests, it returned a 404 with the message that the report data was not found. We are not in it. Not failing, not passing. Absent.

That is not an embarrassing admission, it is the normal condition for a business website serving a city rather than a country. And it has a concrete consequence: if your site is not in the field dataset, the Core Web Vitals input to Google's ranking systems has nothing to read about you. Somebody selling you a Core Web Vitals rescue package is selling you improvements to a signal that is currently blank for your domain.

Speed still matters. The reason is different.

I want to be careful here, because the honest version of this argument is easy to misread as permission to ship a slow website.

Google's page experience documentation is plain that there is no single page experience signal, that good scores do not guarantee top rankings, and that Search still seeks to show the most relevant content even when the page experience is subpar. Relevance wins. Speed is a tiebreaker at best, and for a site with no field data it is not even in play.

But a visitor waiting on a blank screen does not care about any of that. They leave. On a five page site for a local service business, the return on speed work is that more of the people who already found you stay long enough to call. That is a conversion argument, and it survives every algorithm update.

So fix the slow site. Just do it for the customer in the parking lot with one bar of signal, not for a number in a sales email.

The three metrics, and the one that cannot be faked

Current Core Web Vitals, with thresholds straight from web.dev:

Largest Contentful Paint should happen within 2.5 seconds. This is when the biggest thing on screen, usually your hero image or headline, actually appears. It is the closest proxy for whether the site loaded.

Interaction to Next Paint should be 200 milliseconds or less. This is how long the page takes to visibly respond after somebody taps something. It replaced First Input Delay as a stable metric in 2024.

Cumulative Layout Shift should be 0.1 or less. This is the one where you go to tap a button, an image finishes loading above it, the page jumps, and you tap something else.

Now the detail that exposes the whole lab reporting problem. Interaction to Next Paint requires somebody to interact. The INP documentation says the lab value depends entirely on which interactions get performed during measurement, and that Lighthouse falls back to Total Blocking Time as a proxy while explicitly noting it is not a substitute for INP.

Look back at our two test runs. Neither reported an Interaction to Next Paint figure, because nothing tapped anything. They reported Total Blocking Time instead: 90 milliseconds on mobile, 10 on desktop. That means a third of Core Web Vitals is structurally unmeasurable by the tool most speed audits are built on. Any report claiming to have graded your INP from a lab run has graded a proxy and relabeled it.

What I would actually do, in order

1. Run PageSpeed Insights on your homepage and your top service page. Check whether a real user section appears at all. That tells you whether any of this is a ranking question for you yet.
2. Load your own site on your own phone, on cell data, away from your office wifi. This is unscientific and it is more informative than most audits.
3. If it is slow, look at images first. Oversized hero images are the most common cause of a bad Largest Contentful Paint on small business sites, and the fix is compression and correct dimensions rather than a rebuild.
4. Fix layout shift by reserving space for images and embeds. It is cheap, and it is the metric visitors consciously notice.
5. Only then consider anything structural.

Notice that steps one and two cost nothing and rule out most of the expensive answers.

This connects to what we wrote about AI crawlers and raw HTML. Sites that assemble content in the browser fail both tests at once: slow for the visitor, empty for the machine. Sending real content in the initial response is what makes a page fast on cell data and legible to everything else. It is also why accessibility work tends to improve performance as a side effect. One fix, three benefits.

Where we land

We keep The Doggy Den's site fast and current under an ongoing care plan, and performance work is a real line item in that. What it is not is a monthly ranking lever we invoice against. It is maintenance, like keeping software patched, because a site that got fast once does not stay fast once people start adding things to it.

Our own mobile score is 73. I am publishing that rather than hiding it, because a 73 with a 0.8 second desktop paint and zero layout shift is a different situation from a 73 caused by four megabytes of uncompressed photographs, and no single number distinguishes them. That is the actual lesson. A score is a starting question, never a verdict.

If somebody sent you a red number this week, send it to me instead. Our website team will tell you which half of the report it came from, whether your site is in the field dataset at all, and whether the thing it flags is worth money. That is a short conversation and it is free.

Frequently asked questions

My PageSpeed score is 45. Should I panic? Not on that alone. Check the desktop score, check whether real user data exists for your domain, and load the site on your phone on cell data. If all three look bad, you have a real problem worth fixing. If only the throttled mobile lab run looks bad, you have a diagnostic to read, not an emergency.

How long until my site shows up in the real user data? There is no published traffic threshold, so nobody can give you a date honestly. The report covers a rolling 28 day window, so once you cross the line it appears within about a month. Growing traffic is the only lever, which is a content and local search problem rather than a performance one. That is the ground local SEO work covers.

Does a faster site rank higher? All else equal and with field data present, it can contribute. All else is rarely equal. Google states outright that Search seeks the most relevant content even when page experience is subpar, so a faster page about the wrong thing still loses to a slower page about the right thing.

Is it worth paying for a performance audit? Sometimes, if your site is genuinely slow on a real phone and somebody is going to fix it rather than just report it. A report that ends in a number and a package price, with no distinction between lab and field data, is a sales document.

Have your speed report checked