Core Web Vitals are three specific, free measurements Google publishes for every public page: LCP (how fast the biggest thing on the page shows up, good is 2.5 seconds or less), INP (how fast the page responds to a tap, good is 200 milliseconds or less), and CLS (how much the page jumps around while it loads, good is 0.1 or less). You can check your own site's real score for free with Google's PageSpeed Insights tool, which uses actual visitor data when your site gets enough traffic, not just a lab guess. For a home-service site, the failure almost always traces back to a short list: an oversized hero photo, a booking or chat widget loading before the page's real content does, and images or ads with no reserved space that shove the page around as they load in. Fixing the hero photo first is usually also the cheapest fix.
By the numbers
- LCP 2.5s, INP 200ms, CLS 0.1. Google's own published "good" thresholds for the three Core Web Vitals metrics. GOOGLE DOCUMENTED
- INP is a newer metric. It replaced an older one, First Input Delay (FID), as the official responsiveness measurement starting March 12, 2024. A site graded on the old FID rule can look fine and still fail the current INP check. GOOGLE DOCUMENTED
- Loading speed is the one most sites actually fail. Independent analysis of real-world Chrome traffic (CrUX) found 62% of mobile sites pass the LCP check, versus 77% for INP and 81% for CLS. Across all three together, only 48% of mobile sites and 56% of desktop sites pass completely. INDEPENDENT RESEARCH
- 53% of mobile visits are abandoned past the 3-second mark. From Google's own 2017 industry benchmarking study of mobile landing pages, still the most-cited figure of its kind; no larger-scale replication has been published since, so treat it as directionally true, not a precise current-year number. GOOGLE DOCUMENTED
- Core Web Vitals became a Google ranking signal in August 2021, rolled out to mobile search first, alongside mobile-friendliness and HTTPS. Google is explicit that strong content still beats a fast page with weak content. GOOGLE DOCUMENTED
The three checks, in plain terms
Each one measures something different. A site can pass two and still fail the third, and the FAQ handles the overall ranking question separately below.
| Metric | What it actually measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | How long until the biggest visible element, usually a hero photo or headline, finishes rendering | ≤ 2.5s | ≤ 4.0s | > 4.0s |
| INP (Interaction to Next Paint) | How long the page takes to visibly respond to a tap, click, or key press, measured across the whole visit | ≤ 200ms | ≤ 500ms | > 500ms |
| CLS (Cumulative Layout Shift) | How much visible content moves around unexpectedly while the page is loading | ≤ 0.1 | ≤ 0.25 | > 0.25 |
What's actually making a contractor site slow, in order of impact
- An oversized, uncompressed hero photo. A full-resolution photo straight off a phone or a stock-photo site, placed at the top of the homepage, is the single biggest and cheapest-to-fix cause of a failed LCP score. Right-sizing and compressing it before upload usually fixes most of the gap by itself.
- Third-party scripts loading before the page's real content. A booking widget, a chat bubble, a review-badge embed, and a font from an outside service each add their own separate round trip. Loaded carelessly, several of these stacked together can delay both LCP and INP even on a site with an otherwise light homepage.
- Custom web fonts that block rendering. A font file that has to download before any text can paint delays LCP, especially on a slower connection. A fallback system font shown first, swapped in once the custom font loads, avoids the delay.
- Images or embeds with no reserved space. When a browser doesn't know an image or an ad's dimensions ahead of time, the layout has to shift once that content finally loads in. That's exactly what CLS measures, and it's one of the most common, most avoidable layout-shift causes.
- A shared hosting plan serving every visitor from one location. A slower host, or one server location serving a visitor on the other side of the country, adds delay before the page even starts rendering. It's a real factor, but it's usually a smaller piece of the gap than the four causes above, worth checking last.
Three real doubts about this
Mobile-friendly and fast are two different checks. "Mobile-friendly" usually just confirms the layout resizes without breaking. Core Web Vitals measures actual load speed, response time, and visual stability, on real visitor connections. A site can pass one and fail the other.
Your own check is on your own device, often on office Wi-Fi, with the page already cached in your browser from the last time you looked. PageSpeed Insights, used in the quick answer above, shows the number for a fresh visitor on a real connection, including real-world data from actual visitors when the site gets enough traffic to report it.
A caching plugin can genuinely help, especially on a slow host. It does nothing for an oversized hero photo, a layout shift from an image with no set dimensions, or a chat widget loaded before the page's real content. Those three causes, covered above, are usually the bigger share of a failed score.
Questions we get
Frequently asked questions
What is Core Web Vitals, exactly?
Three specific measurements Google publishes and grades every public page against: LCP (loading speed), INP (responsiveness to taps and clicks), and CLS (whether the layout jumps around while loading). Each has its own published "good" threshold, covered in the table above.
How do I check my own site's score for free?
Google's own PageSpeed Insights tool, free and run directly by Google. Paste in your URL and it returns your real LCP, INP, and CLS numbers, using actual visitor data when your site has enough traffic, plus a lab test either way.
What's the difference between a "mobile-friendly" site and one that passes Core Web Vitals?
Mobile-friendly usually just means the layout resizes on a phone without breaking. Core Web Vitals is a separate, stricter check on actual load speed, response time, and visual stability. A site can be mobile-friendly and still fail all three Core Web Vitals checks.
Does fixing Core Web Vitals really affect my Google ranking?
Yes, but it's one signal among several, not a replacement for the page actually answering the search. Google has said directly that strong content on a slower page still beats weak content on a fast one. Worth fixing regardless, since the same slowness that costs ranking signal also costs real visitors who leave before the page finishes loading.
What's the single fastest fix if I can only do one thing?
Compress and right-size the hero photo at the top of your homepage. It's usually the single biggest cause of a failed LCP score, and the cheapest one to fix, often without touching anything else on the page.
Is this something I can fix myself, or does it need a developer?
Compressing a hero image is a do-it-yourself fix. Reordering third-party scripts, fixing font loading, and reserving space for images to stop layout shift usually touch the site's actual code or template, which is where most business owners bring in someone who builds sites for a living. That full build-and-fix service is covered on our website design & conversion page.
Sources
- Google Search Central, Understanding Core Web Vitals and Google search results: the LCP, INP, and CLS thresholds, and Core Web Vitals' role as one of several ranking signals.
- Google Search Central, Introducing INP to Core Web Vitals: the INP metric and its March 12, 2024 rollout as FID's replacement.
- Google Search Central, Understanding page experience in Google Search results: the August 2021 page experience ranking update and the "content still wins" caveat.
- Think with Google / Google & SOASTA, The need for mobile speed (2017): the 53% mobile-visit abandonment figure past the 3-second mark.
- HTTP Archive, Core Web Vitals Technology Report, cited in the 2025 Web Almanac: the per-metric and combined Core Web Vitals pass rates from real-world Chrome (CrUX) data.
The 2017 Google/SOASTA figure is the most-cited benchmark of its kind and has not had a comparable large-scale public replication since; treat it as directionally true rather than a precise current number. Pass-rate figures are a point-in-time snapshot of the open web generally, not specific to home-service sites.