Someone with a burst pipe or a throbbing tooth is searching on their phone, often on one bar of signal. If your page takes ages to show anything, jumps around while it loads, or ignores their taps, they hit back and call the next business. Google measures exactly those moments with three numbers called Core Web Vitals. This lesson explains them in plain words and covers the fixes that usually matter on small-business sites.
Mobile comes first
Google says it "uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking." So the version of your site that counts is the phone version. Make sure it has the same content as the desktop version, with no services hidden on mobile. Google recommends responsive design, where one site adapts to every screen size.
The three Core Web Vitals
| Metric | What it measures | In plain English | Good | Needs improvement | Poor |
|---|---|---|---|---|---|
| LCP: Largest Contentful Paint | When the largest image or text block on screen finishes showing | "How long until I see the main thing?" | 2.5 s or less | 2.5-4.0 s | Over 4.0 s |
| INP: Interaction to Next Paint | How quickly the page responds to taps, clicks and typing | "When I tap, does it react?" | 200 ms or less | 200-500 ms | Over 500 ms |
| CLS: Cumulative Layout Shift | How much things jump around unexpectedly | "Did the button move just as I tapped it?" | 0.1 or less | 0.1-0.25 | Over 0.25 |
All thresholds are from web.dev, Google's web developer site. They're judged at the 75th percentile of real visits, split by mobile and desktop. Put simply, at least three out of four visits should land in the "good" range.
A note on FID. Older articles may mention First Input Delay (FID). Google replaced FID with INP as a Core Web Vital on March 12, 2024. INP looks at responsiveness across the whole visit, where FID only looked at the first tap.
How much this matters for ranking
Google's page experience documentation says "Core Web Vitals are used by our ranking systems." It also says Google "always seeks to show the most relevant content, even if the page experience is sub-par," and that "trying to get a perfect score just for SEO reasons may not be the best use of your time."
In practice, speed won't beat relevance, and you don't need a perfect score. Getting out of the "poor" range is still worth it, mostly because slow, jumpy pages lose customers you already won in search.
How to test with PageSpeed Insights
Go to PageSpeed Insights (pagespeed.web.dev), paste in your page address and run it. You'll get two kinds of data:
| Section | Where it comes from | How to use it |
|---|---|---|
| Field data (real users) | The Chrome User Experience Report: real Chrome visits over the previous 28 days | Core Web Vitals are judged on real-user data like this. Check whether each metric is good, needs improvement or poor. |
| Lab data (a test run) | A Lighthouse test simulating a mid-tier phone on a mobile network | Use it to find causes. The 0-100 score varies between runs. |
Small sites often don't get enough visits for page-level field data. When that happens, PageSpeed Insights falls back to data for your whole site (origin level) or shows only the lab test. That doesn't mean anything is broken.
Test your home page and your most important service page, on the Mobile tab first. Search Console's Core Web Vitals report (lesson 6) shows the same field data grouped across your site.
Five common fixes for small-business sites
These come from web.dev's guidance. They go after the usual suspects on a small-business site: huge photos, sliders, embeds and add-on scripts.
1. Shrink your images
Big photos dropped straight from a phone or camera are a common cause of slow LCP. web.dev recommends sizing images to how big they actually display, compressing them, and using modern image formats. Most website builders and image plugins can do this for you.
2. Don't lazy-load the top image; do lazy-load the rest
Lazy loading means the browser waits to load something until the visitor scrolls near it. web.dev's advice is "Never lazy-load your LCP image." The hero photo at the top should load straight away, and adding fetchpriority="high" to it can help. Images, maps and videos further down the page should use loading="lazy", which works on <iframe> embeds too.
3. Give images and embeds a fixed size
web.dev lists images and embeds without dimensions among the common causes of layout shift. The browser doesn't know how much space to save for them, so the text jumps when they arrive. Set width and height on images, and reserve space for maps, video embeds, review widgets and cookie banners. Web fonts can cause shifts too when they swap in. Stick to one or two.
4. Cut third-party scripts
Chat widgets, review carousels, a pile of analytics tags, social feeds and booking pop-ups each add code that can slow loading and delay responses to taps (INP). web.dev says to audit them regularly, and "if the script doesn't add clear value to your site, remove it." Load the rest with async or defer so they don't block the page.
5. Speed up the server
Nothing appears until your server sends the first piece of the page. web.dev recommends reducing server response time and says a content delivery network (CDN, a network of servers that delivers your site from a location near each visitor) is the best way to reduce how far files travel. Ask your host or web designer whether your site uses caching and a CDN.
A local example
An illustrative example, not a real company. Bluewire Electric is a residential electrician in Charlotte, North Carolina. PageSpeed Insights on the mobile home page showed poor LCP and CLS that needed improvement in the field data.
The lab diagnosis pointed to three things: a 6 MB hero photo inside an auto-playing slider, a review widget that pushed content down as it loaded, and four tracking scripts left over from old ad campaigns.
The fixes took a few hours in the site builder:
- Replaced the slider with one compressed hero photo, not lazy-loaded.
- Reserved a fixed-height space for the review widget and lazy-loaded the embedded map in the footer.
- Removed two unused tracking scripts and set the rest to load with
defer.
Field data updates over a rolling 28 days, so they waited a month before checking the results.
Do this now
What is a good Core Web Vitals score?
Per web.dev: LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real visits.
Is FID still a Core Web Vital?
No. Interaction to Next Paint (INP) replaced First Input Delay as a Core Web Vital on March 12, 2024.
Do I need a 100 PageSpeed score to rank?
No. Google says Core Web Vitals are used by its ranking systems, but relevance comes first and chasing a perfect score just for SEO may not be the best use of your time.
Why does my PageSpeed score change every time I test?
The lab score varies with network and hardware conditions. Focus on the field data, which reflects real visits over the previous 28 days.
Sources
- Web Vitals, web.dev (checked Oct 2026)
- Largest Contentful Paint (LCP), web.dev (checked Oct 2026)
- Interaction to Next Paint (INP), web.dev (checked Oct 2026)
- Cumulative Layout Shift (CLS), web.dev (checked Oct 2026)
- Interaction to Next Paint becomes a Core Web Vital on March 12, web.dev (checked Oct 2026)
- Understanding page experience in Google Search results, Google Search Central (checked Oct 2026)
- Mobile site and mobile-first indexing best practices, Google Search Central (checked Oct 2026)
- About PageSpeed Insights, Google for Developers (checked Oct 2026)
- Optimize Largest Contentful Paint, web.dev (checked Oct 2026)
- Browser-level image lazy loading for the web, web.dev (checked Oct 2026)
- Load Third-Party JavaScript, web.dev (checked Oct 2026)
Want this done for you? Start free