Core Web Vitals for business owners
By Florentina Gjoka · Published June 1, 2026 · Updated July 22, 2026
LCP, INP, and CLS explained in plain English, with Google's current good thresholds.
What are Core Web Vitals?
Core Web Vitals are three user-experience signals Google measures on real visitors: how quickly the main content loads (LCP), how quickly the page responds to interaction (INP), and how much the layout shifts unexpectedly as it loads (CLS). Google uses them as one of many ranking signals.
The measurements come from real Chrome users, not lab tests. Google reports on the 75th percentile of your visitors — meaning a page 'passes' when at least 75% of visitors have a good experience on that metric.
What are the current good thresholds?
Google's current thresholds are: Largest Contentful Paint at or under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. A page needs to be within all three, at the 75th percentile of real users, to be considered good.
- LCP (Largest Contentful Paint) ≤ 2.5 seconds
- INP (Interaction to Next Paint) < 200 milliseconds
- CLS (Cumulative Layout Shift) < 0.1
Do Core Web Vitals affect Google rankings?
Yes, as one of several signals. Google uses Core Web Vitals as part of page experience, which is a ranking factor. They matter more where sites are otherwise similar in quality — a fast page will rarely beat a much better answer, but between two comparable answers, the faster one usually wins.
The practical impact is easiest to see in competitive commercial queries where several sites have similar content quality. In those SERPs, Core Web Vitals are often the tiebreaker.
In queries where one page is clearly the best answer, speed matters less to ranking — but it still matters to conversion. Slow pages lose visitors regardless of ranking.
What most often causes Core Web Vitals failures?
The most common failure causes are large unoptimized hero images, blocking third-party scripts (chat widgets, analytics, ads), web fonts loaded without size reservation, and content injected into the layout after the initial render. Fixing these four categories resolves most failures on marketing sites.
- Large unoptimized hero images — the single most common LCP problem
- Blocking third-party scripts — chat widgets, tag managers, ad scripts
- Fonts loaded without size reservation causing text to reflow
- Ads or embeds injected after initial render, pushing content down
- JavaScript-heavy interactive components that block the main thread
How do you fix each Core Web Vital?
LCP is usually an image or font problem — serve the right size, use a modern format, preload the hero. INP is usually a JavaScript problem — split bundles, defer non-critical scripts, remove heavy third-party tags. CLS is a layout stability problem — reserve space for images, fonts, ads, and embeds.
| Metric | What it measures | Common cause | Typical fix |
|---|---|---|---|
| LCP | Time until largest element renders | Unoptimized hero image or slow server response | Serve responsive images, use WebP/AVIF, preload hero, use CDN |
| INP | Response time to user interactions | Heavy JavaScript blocking the main thread | Code-split, defer scripts, remove unused tags, use web workers |
| CLS | Unexpected layout shifts during load | Images without dimensions, late-loading fonts or ads | Reserve space with width/height, use font-display: swap, size ad slots |
What should you ask your team about Core Web Vitals?
Ask which pages fail thresholds, on which devices, and what the top planned fix is for each. If the answer is 'we don't measure' or 'it's fine,' the answer is wrong — every serious team can name their worst-performing template and the fix in queue for it.
Where do the measurements come from — lab tools like Lighthouse, or real-user data from Chrome UX Report and Search Console? Real-user data is the authoritative source; lab tools are useful for diagnosis but not for reporting.
Key takeaways
- Three signals, three thresholds — LCP ≤ 2.5s, INP < 200ms, CLS < 0.1
- Images and third-party scripts cause most failures
- 75th percentile of real users is what Google uses — not lab tests
- Core Web Vitals are a tiebreaker in competitive SERPs and a conversion factor everywhere
- Ask your team which pages fail, on which devices, and what the fix is
FAQ
Do Core Web Vitals affect Google rankings?+
Yes, as one of several page experience signals. They matter more where sites are otherwise similar in quality — a fast page will rarely beat a much better answer, but between two comparable answers, the faster one usually wins.
How do we measure our current Core Web Vitals?+
Google Search Console's Core Web Vitals report is the authoritative view for your site, using real Chrome user data. PageSpeed Insights gives per-URL diagnostics. Lighthouse in DevTools is useful for debugging specific pages but is a lab test, not a real-user measurement.
How fast should a website really load?+
For LCP, the good threshold is 2.5 seconds or less at the 75th percentile of real users. In practice, aim for 2.0 seconds so you have headroom for slow connections and busy days. Faster is always better for conversion even after passing Google's threshold.
Are chat widgets and marketing tags really that damaging?+
Often yes. A single heavy chat script or tag manager container loading dozens of tags can add hundreds of milliseconds to INP and push otherwise-fine pages into the failing bucket. Audit third-party scripts twice a year and remove ones no team owns anymore.
Related articles
Why web design and SEO should be planned together
How joint planning changes architecture, content, UX, performance, internal links, and launch workflow.
How to redesign a website without losing SEO
Inventory, benchmarks, redirects, metadata, staging controls, and the checks that protect search equity.
Want to write for us?
We publish guest articles from practitioners in web design, SEO and digital marketing — with one receipt per pitch.