Core Web Vitals in 2026 are three metrics: Largest Contentful Paint under 2.5 seconds (loading), Interaction to Next Paint under 200 milliseconds (responsiveness), and Cumulative Layout Shift under 0.1 (visual stability). INP replaced First Input Delay in March 2024. The thresholds are pass-fail at the 75th percentile of real user data, not lab data. Google confirms CWV is used in ranking, but won't say how much, and an empty page that loads fast still ranks badly because content quality dominates.
That's the whole shape of it, and everything else is implementation. Let me walk through what actually matters when you ship.
The three metrics, with the thresholds Google publishes
Per Google's Core Web Vitals documentation:
LCP, Largest Contentful Paint. When did the largest visible content element finish rendering? Good is under 2.5 seconds, needs-improvement is 2.5 to 4 seconds, poor is over 4 seconds. The "largest" is usually a hero image, video thumbnail, or large H1 block. Time-to-first-byte is a sub-metric.
INP, Interaction to Next Paint. How fast does the page paint a response to a user's interaction (click, tap, key press)? Good is under 200ms, needs-improvement is 200 to 500ms, poor is over 500ms. INP replaced FID in March 2024. The critical difference is that INP samples all interactions on the page and reports the slowest, where FID only measured the first.
CLS, Cumulative Layout Shift. How much does content shift around as the page loads? The score is unitless, lower is better: good is under 0.1, needs-improvement is 0.1 to 0.25, poor is over 0.25. The classic CLS killer is an ad slot or image without explicit dimensions pushing text down after the user starts reading.
Why INP replaced FID, and what changed
Rick Viscomi, Chrome's web performance DevRel, said it plainly on SOTR 071: FID was "overly permissive." Roughly 99.9% of desktop sites and 95% of mobile sites passed FID. A metric almost everyone passes isn't measuring anything.
INP fixes that. It looks at every interaction on the page (every click, every keypress, every tap) and surfaces the slowest. The number gets worse than your old FID score, but it's not a regression, it's the new metric exposing slowness FID was hiding.
> Per Mueller on SOTR 071: "We do use these in our ranking systems or in Search systems. The details we tend not to go into. We don't go into thresholds."
So yes, CWV affects ranking. But the magnitude is undisclosed, and an empty page that loads in 200ms still won't rank because content quality is a separately weighted set of systems.
Field data vs lab data: the single most expensive mistake
This is where most teams burn weeks of engineering. Lab data and field data are different things that measure different things, and disagreeing between them is the normal case.
Lab data comes from synthetic tools like Lighthouse. The browser is throttled to simulate a worst-case slow mobile device on a slow connection, and the page loads in a controlled emulator. It's useful for debugging and reproducible regression tests, but not for measuring real users.
Field data comes from the Chrome User Experience Report (CrUX), which aggregates anonymized real-user metrics from opted-in Chrome users. It's available as origin-level data for any site that has enough traffic, and sometimes page-level data if traffic is high enough.
The 75th-percentile rule applies to field data. "Good" doesn't mean median. It means three quarters of real-user experiences hit the threshold. If your INP is 280ms at the 75th percentile, you're in "needs improvement," not "good," even if your median is 150ms.
Lighthouse can't measure INP at all in a meaningful way because Lighthouse doesn't actually click anything. It uses Total Blocking Time as a lab proxy. That's why a Lighthouse score of "40-something red" can coexist with a real-user CWV pass, and vice versa. Don't pick one and ignore the other: use Lighthouse to find what to fix, and use CrUX to know if real users are still struggling.
PageSpeed Insights blends both, showing CrUX field data at the top of the report and Lighthouse lab data at the bottom, and mixing the two is the cause of 90% of "but my CWV passes!" arguments.
What "Core Web Vitals failures" usually mean
After enough audits, a pattern: most CWV failures on small business sites are JavaScript bloat. Specifically:
- Multi-megabyte JavaScript bundles that ship analytics, A/B testing, heatmaps, chat widgets, consent managers, and a CRM tracker on every page. Each delays main-thread work, which delays INP and pushes LCP back.
- Render-blocking third-party scripts in the head (fonts, analytics, tag managers) that block the browser from painting until they resolve.
- Layout shift from un-dimensioned media: images, videos, and ads without explicit width/height attributes, plus late-loading web fonts swapping in.
- Single Page App route transitions that throw away the page and rebuild it client-side, costing a fresh LCP each navigation.
> Most CWV failures are not server speed. They're the script tags you added one at a time, without ever removing one. The fix is rarely a CDN. The fix is an audit of what's on the page.
WordPress sites in particular accumulate this fast. Every plugin ships scripts. Bundle them and you hit INP cliffs you wouldn't predict from code review.
Page experience is one signal, not THE signal
The page-experience signal exists. CWV is part of it. So is HTTPS, mobile-friendliness, and the absence of intrusive interstitials. But Google's own page-experience FAQ is explicit: "There is no single signal. Our core ranking systems look at a variety of signals."
The trap is treating CWV as a binary pass/fail that decides ranking, which it isn't. A site with great content and "needs improvement" CWV will outrank a site with terrible content and perfect CWV. Mueller on SOTR 071: "I have Core Web Vitals check. I will now rank well, that's a misunderstanding."
The right mental model: CWV is a hygiene minimum. Pass the thresholds at the 75th percentile of field data, then forget the score and spend your engineering time on what differentiates the page.
Intrusive interstitials are a separate penalty
The interstitial check sits next to CWV in Google's page-experience guidance, not inside it. The rule: pop-ups that cover the main content on mobile shortly after the user arrives can demote the page in mobile search.
Exemptions exist for legally required interstitials (age gates, cookie consent banners that don't block content) and for login walls on private content. The pattern Google penalises is the marketing modal that interrupts the user the moment they arrive on the page.
For full context on what else feeds into the broader picture, see the 2026 SEO reality pillar, the structured data spoke that pairs technical eligibility with content quality, and the JavaScript SEO breakdown for what Googlebot actually executes when it visits.
A four-step audit that resolves most CWV failures
When the studio takes on a CWV-blocked site, the loop is consistent:
- Pull CrUX field data. Search Console's Core Web Vitals report or PageSpeed Insights gives you the 75th-percentile values. This is the only number that matters for ranking impact.
- Add instrumentation. Install web-vitals.js and pipe metrics to your analytics. Lab data tells you potential issues; field data tells you what real users are hitting, and without instrumentation you're guessing.
- Audit your JavaScript. Open the Network tab, sort by transfer size, and count the third-party scripts. Most sites can remove 30 to 50% of their JS payload by killing dead tag-manager triggers and unused analytics tools.
- Fix the highest-impact metric first. INP failures usually come from a small number of long tasks, and the Long Animation Frames API makes them attributable. LCP failures usually come from a slow hero image or a render-blocking font. CLS failures are almost always missing dimensions on media.
That's the work. There's nothing magic about CWV; it's a measurable hygiene loop you can instrument and close.
Sources
- Understanding Core Web Vitals and Google Search results (Google Search Central)
- Understanding page experience in Google Search results (Google Search Central)
- Avoid intrusive interstitials and dialogs (Google Search Central)
- Deciphering INP and Core Web Vitals (SOTR 071) (Search Off the Record podcast, March 2024)