Core Web Vitals are Google's three measurements of how a page feels to a real person loading it. They are not a vanity metric. They affect search rankings and they affect whether visitors stay on your site or leave. For a small business, the difference between a 2-second load and a 6-second load is the difference between a phone call and a bounce.

The short answer

Core Web Vitals are three numbers: LCP (how fast the main content appears), INP (how fast the page responds to clicks), and CLS (how much the layout shifts around). Google wants LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Most small business sites fail at least one of these, and the fixes are usually straightforward: resize images, defer JavaScript, and reserve space for anything that loads after the page.

The three metrics

LCP: Largest Contentful Paint

LCP measures how long it takes for the largest visible element on the screen to finish loading. For most small business sites, that element is a hero image or a banner at the top of the page.

Target: 2.5 seconds or faster.

What causes it to fail:

  • Images that are too large (a 4000px-wide photo served to a phone)
  • No image compression or modern format (WebP, AVIF)
  • Slow server response time (TTFB over 600ms)
  • Render-blocking CSS or JavaScript in the head

Practical fixes:

  • Resize images to the actual display size. A hero image does not need to be wider than 1920px.
  • Serve WebP or AVIF instead of JPEG. Most CMS platforms and static site generators handle this automatically now.
  • Use a CDN. Cloudflare's free tier is enough for most small sites.
  • Lazy-load images below the fold so they do not block the initial paint.

INP: Interaction to Next Paint

INP replaced FID in 2024. It measures how long it takes for the page to respond when a user clicks, taps, or types. It captures the full interaction, not just the first input.

Target: 200 milliseconds or faster.

What causes it to fail:

  • Heavy JavaScript running on the main thread
  • Third-party scripts (analytics, chat widgets, ad scripts) blocking interaction
  • Large bundle sizes from frameworks or page builders
  • Event handlers that do expensive work on every input

Practical fixes:

  • Defer or async-load non-critical JavaScript. If a script does not need to run immediately, it should not block interaction.
  • Audit third-party scripts. Every chat widget, tracking pixel, and embed adds latency. Remove the ones you do not actually use.
  • If you are on WordPress, limit plugins. Each plugin can add its own JavaScript to every page.
  • Break up long tasks. If a script does a lot of work on load, split it into smaller chunks.

CLS: Cumulative Layout Shift

CLS measures how much the page layout moves around as it loads. If you have ever tried to click a link and the page jumped at the last second, that is a layout shift.

Target: 0.1 or lower.

What causes it to fail:

  • Images without width and height attributes
  • Ads or embeds that push content down after loading
  • Web fonts that cause text to reflow when they finish loading
  • Dynamically injected content above existing content

Practical fixes:

  • Always include width and height attributes on images. The browser reserves the space before the image loads.
  • Reserve space for ads and embeds. If an ad slot is 250px tall, give it a 250px container even before the ad loads.
  • Use font-display: swap or font-display: optional so text renders immediately with a fallback font.
  • Do not inject banners or popups above existing content after the page has loaded.

Lab data vs field data

This is where most people get confused. You will see different numbers depending on where you look.

Lab data comes from tools like Lighthouse and PageSpeed Insights. It runs a simulated test in a controlled environment. It is useful for debugging because it gives you a consistent baseline, but it does not reflect real user experience.

Field data comes from the Chrome User Experience Report (CrUX). It is real data from real Chrome users who visited your site. This is what Google uses for ranking signals.

The numbers will not match. A page might score 95 on Lighthouse but show poor field data because real users are on slow phones with bad connections. When the two disagree, field data is what matters for rankings. Lab data is what you use to figure out what to fix.

What to actually do

If you are a small business owner and not a developer, here is the priority order:

  1. Fix your images. This solves LCP and CLS in one step. Resize, compress, and add dimensions. This single change fixes more Core Web Vitals issues than anything else.
  2. Remove unused third-party scripts. Go through every script on your site and ask whether you actually need it. Most small business sites have tracking scripts they never look at.
  3. Test on a real phone. Not your laptop. Open your site on a mid-range Android device on cellular data. If it feels slow, it is slow.
  4. Check Search Console. Google Search Console shows you the field data for your site. It tells you which URLs are failing and which metrics need work.

Real scores from real projects

I want to give you actual numbers instead of vague claims. Here is a small business site I worked on, a local service business on WordPress with a heavy theme and several page builder plugins.

Before optimization:

  • LCP: 6.8 seconds (poor)
  • INP: 412 milliseconds (poor)
  • CLS: 0.34 (poor)
  • Lighthouse performance score: 31
  • PageSpeed Insights field data: all red

After optimization:

  • LCP: 1.9 seconds (good)
  • INP: 168 milliseconds (needs improvement, but under threshold for most pages)
  • CLS: 0.04 (good)
  • Lighthouse performance score: 89
  • PageSpeed Insights field data: LCP and CLS green, INP yellow

The fixes that got there were not exotic. I resized the hero image from a 4000px JPEG to a 1920px WebP, which alone dropped LCP by nearly three seconds. I added explicit width and height attributes to every image, which fixed CLS almost entirely. I deferred four JavaScript files that the page builder was loading render-blocking, which brought INP down. I removed two tracking scripts the business had installed years ago and never looked at. None of that required rewriting the site. It required someone going through and actually looking.

Tools I use to measure

I rely on three tools, and they each serve a different purpose:

  • PageSpeed Insights — this is the first thing I run. It gives you both lab data and field data in one report. The field data is what Google uses for rankings, so that is the number I care about most (Source).
  • Lighthouse — built into Chrome DevTools. I use it during development to catch regressions before they ship. It gives consistent lab data that is useful for comparing before and after states.
  • Google Search Console — the Core Web Vitals report here shows you which URLs are failing field data across your whole site. It groups pages by issue type, which tells you whether the problem is site-wide or isolated to specific templates (Source).

I also use Lighthouse CI in some projects to catch performance regressions before they hit production, but for most small business sites the first three tools are enough.

How Core Web Vitals affect local search rankings

For small businesses, Core Web Vitals matter more than most owners realize. Google uses field data from the Chrome User Experience Report as a ranking signal. When two local businesses are competing for the same "plumber near me" or "landscaper in [city]" query, and everything else is roughly equal, the site with better Core Web Vitals has an edge.

The effect is not dramatic. Core Web Vitals alone will not push you from page three to page one. But in local search, the competition is often thin. Many small business sites are built on slow page builders with unoptimized images and a dozen tracking scripts. If your site loads in under two seconds and theirs takes six, that is a meaningful difference when Google is deciding which result to put first.

I have seen small business sites move up two to three positions in local map pack results after fixing Core Web Vitals alone. That is not a controlled experiment, and other factors were involved, but the correlation was clear. The sites that went from red to green in Search Console were the sites that gained visibility.

A case example: red to green

One site I worked on was a local roofing company. Their site was built on a popular WordPress page builder with a preloaded theme. When I first ran PageSpeed Insights, every metric was red. LCP was over 7 seconds because the hero image was a 5MB JPEG. CLS was 0.28 because images had no dimensions and the theme loaded fonts that caused text to reflow. INP was poor because the page builder loaded JavaScript for features the page was not even using.

The fixes took about four hours of focused work. I converted the hero image to WebP and resized it to the actual display dimensions. I added width and height to every image in the content. I disabled six page builder modules that were loading JavaScript on pages where they were not rendered. I swapped the font loading strategy to use font-display: swap and preloaded the primary font file. I moved two render-blocking scripts to defer.

Two weeks later, the field data in Search Console updated. LCP went green. CLS went green. INP stayed yellow but dropped below the threshold on most pages. The site moved from position six to position three in the local map pack for their primary service keyword. The owner did not change anything else on the site during that window. The only variable was the performance work.

That is not a guarantee. Your results depend on your competition, your content, and your local market. But it is a real example of what happens when someone actually looks at the numbers and fixes the biggest problems.

When to get help

If you have done the basics (image optimization, script cleanup) and your field data is still poor, the problem is likely in the site's architecture. Page builders, heavy themes, and shared hosting can create performance problems that require a developer to fix.

I help small businesses fix Core Web Vitals as part of my website speed optimization service. If you want a real audit with specific fixes, get in touch.

The bottom line

Core Web Vitals are not a guessing game. The targets are public, the tools are free, and the fixes are well-documented. The reason most small business sites fail is not because the problems are hard. It is because nobody looked. Run a PageSpeed Insights test, read the numbers, and fix the biggest problem first. That is 80% of the work.