Core Web Vitals are three numbers Google uses to judge how a page feels to a real person: how quickly the main content shows up (LCP), how fast the page responds when you tap or click (INP), and how much things jump around while it loads (CLS). Google publishes a “good” threshold for each — LCP at or under 2.5 seconds, INP at or under 200 milliseconds, and CLS at or under 0.1.
Do they affect rankings? Yes, but modestly. They are part of Google’s page experience signals, and Google has been consistent that relevant, helpful content matters more. Think of them as a tie-breaker between pages that are otherwise close — and as a conversion problem that costs you customers whether or not Google is watching.
Below: what each metric measures, where to check yours, why your numbers may not match Google’s, and the problems behind most failing small-business sites.
Core Web Vitals explained: LCP, INP, and CLS in plain English
Each metric answers a question a visitor would ask without knowing the vocabulary.
LCP: Largest Contentful Paint
The question: “How long until the main thing is on my screen?” LCP measures the time from when the page starts loading until the largest visible element — usually the hero image (the big photo at the top), a video poster, or a block of headline text — finishes rendering. Good is 2.5 seconds or less.
LCP is the one to check first on a small-business site, and when it fails, images are usually why — with slow hosting and heavy scripts close behind.
INP: Interaction to Next Paint
The question: “When I tap something, does the page respond?” INP watches every click, tap, and key press and reports how long the page took to visibly react to the slowest one (ignoring the occasional outlier on busy pages) — so a single sluggish menu, form, or chat widget can fail the whole page. Good is 200 milliseconds or less.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID measured only the first interaction and only the initial delay; INP covers the whole visit through to the screen updating, which is much harder to pass on a JavaScript-heavy page.
CLS: Cumulative Layout Shift
The question: “Did the page jump while I was reading it?” CLS scores how much visible content moves unexpectedly — the banner that pushes the paragraph down, the button that slides just as you reach for it. It is a unitless number (0.1 or less is good), and it has nothing to do with speed: a fast page can have terrible CLS if images load without reserved space or a cookie notice shoves everything down.
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP | Time until the largest element renders | ≤ 2.5 s | > 4.0 s |
| INP | Delay from interaction to screen update | ≤ 200 ms | > 500 ms |
| CLS | Unexpected content movement | ≤ 0.1 | > 0.25 |
One detail that trips people up: Google grades the 75th percentile, not the average — three out of four page loads have to hit “good” for the page to pass. Your office connection in Plano is not the visitor Google is worried about; it is the one on a mid-range phone with two bars in a parking lot.
Field data vs. lab data: why your scores disagree
Run the same page through two tools and you will get two different answers. That is not a bug: there are two kinds of data, measuring different things.
Field data comes from real Chrome users who opted in to share anonymous performance data. Google collects it in the Chrome User Experience Report (CrUX), and it is what the ranking signal uses: real devices, real connections, real behavior, aggregated over a rolling 28-day window.
Lab data comes from a simulated visit: a tool like Lighthouse loads your page once under fixed, throttled conditions and reports what it saw. It is repeatable and useful for diagnosis, but nobody actually visited your site.
Which one matters for rankings? Field data, full stop. Lab data is the mechanic’s diagnostic; field data is the car actually driving around Fort Worth. A page can score 95 in the lab and still fail in the field because real visitors are on older phones, or because a chat widget the lab never clicked drags INP down for people who do.
How to check your Core Web Vitals
You need two free tools and about ten minutes.
PageSpeed Insights
Paste a URL into Google’s PageSpeed Insights and it shows both kinds of data. The top section is field data from CrUX for that URL — or, if the page is too quiet, for your whole site — and a passing badge there is the goal. The lower section is a lab run with a score and diagnostics; the score out of 100 is a guide, not the target. Check mobile first: that is where sites tend to fail and, for most local businesses, where the majority of visitors are — your analytics will confirm.
The Search Console Core Web Vitals report
PageSpeed Insights checks one page at a time. The Core Web Vitals report in Google Search Console checks your whole site, sorting URLs into Good, Needs improvement, and Poor, with mobile and desktop reported separately. It groups similar pages, so a failing template — every service page built the same way, say — shows up as one problem with one fix.
If you have never opened Search Console, that report alone is reason enough to set it up; it is also where you confirm a fix worked.
Why small-business sites fail (and what fixes each one)
Plumbers’, dentists’, law firms’, and contractors’ sites tend to fail for the same boring reasons — and boring problems have known fixes.
Page builders and bloated themes
Drag-and-drop builders and multipurpose themes ship every feature anyone might use, on every page, whether you use it or not: lots of CSS and JavaScript downloading before your headline can render (hurts LCP), and lots of script competing for the browser’s attention afterward (hurts INP).
The fix, in order of effort: remove plugins and builder modules you don’t use; turn on minification (stripping whitespace and comments from code files) and any “load only what’s needed” option; and add caching, so repeat visitors get a saved copy instead of a freshly built page. If that isn’t enough — and your host isn’t the bottleneck (more below) — the platform itself is usually the problem. It is one reason we build sites by hand: every kilobyte is there on purpose, and green vitals are part of the spec from day one rather than a cleanup task.
Uncompressed and oversized images
The classic LCP problem: a 4,000-pixel-wide photo straight off a phone, displayed at 800 pixels, still downloads at full size. Multiply by a hero, a few team photos, and a gallery, and the page is megabytes heavy before anything else loads.
Fixes: resize images to the largest size they will actually display, export them as WebP or AVIF (modern formats that are much smaller at the same quality), and compress them. Give the hero image priority with fetchpriority="high" and lazy-load everything below the fold (anything you have to scroll to see) with loading="lazy" — but never lazy-load the LCP image itself; that common mistake makes things worse.
Slow hosting
LCP can’t start until the server sends the first byte, and on crowded shared hosting that alone can take a second. PageSpeed Insights flags it as “Reduce initial server response time.” If yours is over about 800 milliseconds, enable page caching, put a CDN in front of the site (servers that hand out copies of your pages from near the visitor), or move hosts. No amount of image work fixes a slow server.
Third-party scripts
Chat widgets, booking tools, review sliders, heat maps, three tracking pixels, a social plugin from 2019. Each is a script from someone else’s server that must download and run, competing with your own page for the browser’s main thread — the single lane where it does all its work. They are the first place to look when a page passes LCP and CLS but fails INP.
Fixes: audit your tag manager (the tool, usually Google Tag Manager, that loads tracking scripts) and remove anything nobody looks at. Load what remains after the page is interactive, and load page-specific widgets — a booking form, say — only on that page. A chatbot can coexist with green vitals if it loads after the content, which is how we approach the AI chatbots we build.
Layout shift from missing dimensions
CLS failures come from elements that arrive late and push things around: images without width and height attributes, web fonts that swap in and reflow text, promo bars injected at the top, and embeds that expand once they load.
Fixes: set explicit width and height on every image and embed so the browser reserves the space, preload your main font and stick to two or three weights, and give banners a fixed slot instead of inserting them above content. Google’s Core Web Vitals documentation goes deeper on each metric.
How much Core Web Vitals actually affect rankings
Every guide to Core Web Vitals owes you this part, and most either overstate it or skip it. Google confirms Core Web Vitals are a page experience ranking signal but has never said how much weight they carry. Its page experience documentation says Search still aims to show the most relevant content even when the experience is sub-par, and that experience matters most when many pages are equally helpful. In practice, a slow page with the best answer usually outranks a fast page with a thin one.
Where vitals matter is at the margins. Say you run a roofing company in Arlington, and two competitors have similar service pages, reviews, and links. Vitals can be the thing that separates you — a tie-breaker, and local service searches are full of ties.
The other reason to care has nothing to do with the algorithm: a slow, jumpy page loses the people who did find you. A button that moves as someone taps it is a lost call.
What vitals will not do is rescue a site with weak content, no local relevance, or a neglected Google Business Profile. Fix those first; our technical SEO checklist puts vitals in context with the other fixes.
What to fix first when your site fails Core Web Vitals
If your site fails today, here is our sequence, highest impact first.
- Get the verdict. Run your home page and top three service pages through PageSpeed Insights on mobile. Note which metric fails, not just the score.
- Fix the hero image. Resize, compress, convert to WebP, and make sure it isn’t lazy-loaded. This alone flips many LCP failures.
- Cut third-party scripts. Open your tag manager or plugin list and remove what nobody uses. Defer the rest — tell the browser to load them after the page is usable.
- Reserve space. Add dimensions to images and embeds. Move the promo bar.
- Trim the platform. Disable unused builder modules and plugins, enable caching, minify assets, and move off slow shared hosting if server response is the bottleneck.
- Wait and verify. Check the Search Console report in three to four weeks. Field data lags.
If step five isn’t enough, you are probably looking at a rebuild — the moment to get the rest of your technical SEO right. Our redesign migration checklist covers doing that without losing the rankings you have.
What a site built for green vitals looks like
Performance is a structural decision — how much code ships, how images are handled, what loads when — not a plugin you add later. That is why every site we build targets green Core Web Vitals from the start, and why SEO is part of the build rather than a separate phase. Whoever builds your next site, ask for these:
- No page-builder runtime shipped to visitors; the editing tool stays in the editor.
- Images resized and converted to WebP or AVIF at build time, with the hero image marked
fetchpriority="high". - Fonts served from your own domain, limited to two weights, with space reserved so text doesn’t reflow.
- Third-party scripts loaded after the content is interactive, never before.
A developer who can’t say yes to all four is selling you a retrofit. Our process page shows how we sequence a build; our pricing page shows what each option costs.
Key takeaways
- Core Web Vitals are three metrics — LCP (good ≤ 2.5 s), INP (good ≤ 200 ms), and CLS (good ≤ 0.1) — graded at the 75th percentile of real visits.
- Field data from real Chrome users is what Google uses for rankings; lab scores are for diagnosis.
- Check one page in PageSpeed Insights and your whole site in the Search Console Core Web Vitals report.
- INP replaced FID in March 2024 and is much harder to pass on script-heavy pages.
- Failures on small-business sites usually trace back to oversized images, slow hosting, page-builder bloat, third-party scripts, and elements without reserved space.
- Vitals are a tie-breaker, not a shortcut — relevant content and local signals matter more.
- Field data updates over a rolling 28-day window, so verify fixes in Search Console after three to four weeks.
Frequently asked questions
No. The score out of 100 is a lab result from a single simulated visit. Passing means the field data from real visitors meets all three thresholds at the 75th percentile, which is a separate section at the top of the same report.
Both, and Google evaluates them separately. Mobile is usually where sites fail and, for most local-service businesses, where the bulk of traffic comes from — so fix mobile first.
Google needs a minimum number of real Chrome visits over the past 28 days to report field data, and many small-business sites don’t reach it. Use the lab diagnostics in PageSpeed Insights to find obvious problems in the meantime.
Yes, plenty do. What matters is what is stacked on top: a lean theme, resized images, and a short list of scripts will usually get there on any platform. The trouble starts when a heavy builder, a dozen plugins, and three chat widgets all load on every page — at that point trimming may not be enough.
Field data is aggregated over a rolling 28-day window, so expect three to four weeks before the Search Console report reflects a fix. PageSpeed Insights lab results change immediately, which lets you confirm image and layout fixes (LCP, load-time CLS) right away. Lab runs can’t measure INP — they report Total Blocking Time as a stand-in — so for script and responsiveness fixes, field data is the only real confirmation.
Failing on mobile and not sure why?
Not sure whether yours is a fix or a rebuild? Get in touch and we’ll talk it through in plain English — no pressure, no jargon. If it turns out to be a rebuild, a Starter Website is $1,500 one-time for up to five pages, most launch in two to four weeks, and you own the domain, the content, and the code.