Core Web Vitals are measured on real visits, most of which happen on mid range phones over cellular connections. A site that loads instantly on a desktop with fiber can still fail all three metrics in the field, because the desktop test never pays for the slow processor, the weak radio, or the cold cache.
Why your test and Google's disagree
There are two kinds of speed measurement and they answer different questions. Lab data comes from a simulated load in a controlled environment. Field data comes from actual Chrome users who visited your site, and it is the field data that feeds Core Web Vitals.
The gap between them is mostly hardware and network. A modern laptop parses and executes JavaScript several times faster than the phone a typical customer is holding. Your office connection has no packet loss. Your browser already has the fonts and scripts cached from the last time you looked.
The number that matters is the one measured on a stranger's phone in a parking lot.
This is why a site can score well in a one off test and still show a failing assessment in Search Console. The test told you what the site can do. The field data tells you what it does.
What each metric is actually measuring
Largest Contentful Paint
How long until the biggest thing above the fold appears. On a service site that is usually the hero image or the headline. It is dominated by server response time, render blocking resources in the head, and image weight.
Interaction to Next Paint
How long the page takes to visibly respond when someone taps something. This is the metric that punishes heavy JavaScript, because a busy main thread cannot repaint until it finishes what it is doing. On a phone, the main thread is busy far longer than you would guess from a desktop profile.
Cumulative Layout Shift
How much the content jumps around while loading. Images without dimensions, fonts that swap to a different size, and banners injected above existing content are the usual causes. It is the cheapest of the three to fix and the most irritating to visitors.
| Metric | What it feels like | Most common cause on a small site |
|---|---|---|
| Largest Contentful Paint | Blank screen for too long | Oversized hero image, slow host |
| Interaction to Next Paint | Tap does nothing for a moment | Plugin scripts running on every page |
| Cumulative Layout Shift | The button moved as I pressed it | Images and ads without reserved space |
The order that gets results
Most small business sites are slow for four or five reasons, and two of them account for the bulk of it. Work in this order rather than trying to act on every line of a test report.
- Serve correctly sized images in a modern format. A hero exported at 3000 pixels wide and displayed at 390 is the single most common defect.
- Give every image explicit width and height attributes so the browser can reserve space before the file arrives.
- Audit your plugins and remove the ones loading scripts on pages that do not use them. A slider plugin loading on every page of the site is common and pointless.
- Preload the font you actually use above the fold, and let the rest swap.
- Check the host. A slow first byte cannot be optimized away in the browser, and shared hosting on an oversold server will cap everything else you do.
Open your homepage on your own phone with wifi turned off, on a fresh tab, and count. If it feels slow to you, it is worse for a visitor who has never been there before.
What changes, and when
Field data updates on a rolling window of recent visits, so a fix made today does not show up in Search Console today. Expect several weeks before the assessment moves, and longer on a site with modest traffic, because the sample fills slowly.
It is also worth being honest about what speed buys. It is a real ranking input and a much more real conversion input. A site that fails all three metrics is leaking visitors who left before they saw anything. A site that passes comfortably does not get promoted for passing harder.
How to improve Core Web Vitals on a small business site
- Serve correctly sized images in a modern format.
- Add explicit width and height to every image.
- Remove plugin scripts from pages that do not use them.
- Preload the above the fold font and let the rest swap.
- Check server response time and change host if the first byte is slow.
Questions people ask
Do Core Web Vitals affect rankings?
They are part of the page experience signals and act as a tiebreaker rather than a primary factor. Content relevance still decides most results. Speed decides how many of the people who arrive stay.
Why does my score change every time I test it?
Lab tests vary with server load, network conditions, and which third party scripts happen to respond slowly that second. Run the test several times and look at the range, not a single number.
Is a caching plugin enough?
It helps first byte time considerably and does nothing for image weight, layout shift, or main thread work. It is one of five things, not the whole job.
Should I worry about a desktop score if my traffic is mobile?
No. Assess on the device profile that matches your visitors. For most local service businesses that is overwhelmingly mobile.
What is a reasonable target?
Passing the three thresholds on mobile field data. Chasing a perfect lab score past that point usually costs more than it returns.
Can a page builder site pass?
Yes, though it takes more care, because builders tend to load stylesheets and scripts for features the page does not use. Trimming what loads matters more than the builder you chose.
If the field data says one thing and your test says another, the technical review starts with what real visits recorded rather than with a score.
Founder of Big Brain Digital. More than 15 years across SEO, content operations, ecommerce, and AI search. Based in Boise. More about Chris.