What are the Core Web Vitals thresholds in 2026?

Three numbers at the 75th percentile of real mobile users. LCP (Largest Contentful Paint) under 2.5 seconds. INP (Interaction to Next Paint) under 200 milliseconds. CLS (Cumulative Layout Shift) under 0.1. Miss any one and Search Console flags the page as "needs improvement." Google measures all three through CrUX, a 28-day rolling field dataset from real Chrome users. PageSpeed Insights and Search Console pull from that same source. Lighthouse runs synthetic lab tests that only approximate the field number. Lab predicts, field ranks. Field data is what decides whether the page that does rank stays ranked.

How do I fix a slow LCP score?

Four fixes, ranked by leverage. First, preload the LCP image with a link rel=preload tag and fetchpriority=high in the head, or set priority on the Next.js Image component. We have seen LCP drop 800ms to 1.4s from this single change. Second, self-host critical fonts with font-display swap instead of pulling from Google Fonts. Third, cache HTML at the edge to push TTFB under 600ms (Vercel, Cloudflare, Fastly). Fourth, inline critical CSS and defer the rest. Never lazy-load the LCP element. That reflex makes scores worse.

Why is INP harder to fix than LCP?

INP measures the worst interaction delay on the page, not the first. A clean LCP can still ship with a failing INP because of one slow click handler. The four fixes: break up long tasks over 50ms using scheduler.yield, setTimeout, or React 18 useTransition and useDeferredValue. Lazy-load third-party scripts like Intercom, HubSpot, Drift, and Segment with Next.js Script strategy=lazyOnload or Partytown. Debounce input handlers at 150ms. Code-split heavy libraries (charts, editors, PDF viewers) with dynamic imports. Always check mobile field scores in PageSpeed Insights, not desktop lab scores.

What is the difference between field and lab Core Web Vitals data?

Field data is what ranks. Lab data is how you debug. Field data comes from CrUX, a 28-day rolling dataset built from opted-in real Chrome users. Lab data comes from Lighthouse running synthetic tests in a controlled environment. PageSpeed Insights shows both. The lab number predicts what the field number will become. The field number is what Google uses as a signal. If your engineering team has spent six months improving performance and CrUX scores have not moved, the work is not reaching real users. Fix templates, not individual pages.

When is Core Web Vitals a platform problem instead of a code problem?

Three tells. A WordPress theme with 40+ plugins, none lazy-loaded. A Shopify storefront with 12 third-party apps injecting render-blocking scripts. A custom React SPA with no server-side rendering and no edge caching. If LCP is 5+ seconds on a content page and you have already applied image, font, and TTFB fixes, the platform is the bottleneck. Migrating to Next.js on Vercel typically moves LCP from 4-6s to under 2s and INP from 400ms to under 150ms. At that point you are having a rebuild conversation, not a performance tuning one.

Core Web Vitals: The SEO Performance Playbook for Modern Sites 2026

Core Web Vitals don't directly rank you. They decide whether the page that does rank stays ranked. Google uses them as a tiebreaker between two pages with similar relevance, and AI crawlers partially render the ones that load too slowly.

Core Web Vitals are the three field metrics Google uses to score real user experience: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). To pass in 2026, your 75th-percentile mobile session needs LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1.[1] Miss any one of those, and the page is flagged as "needs improvement" in Search Console.

Why Core Web Vitals Still Matter in 2026

The page experience signal didn't go away. It got quieter and more important.

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID measured only the first interaction. INP measures the worst.[2]
Google's AI Overviews and generative search results still pull from the same index. Pages that fail CWV at the 75th percentile get crawled less aggressively and partially rendered by AI engines.
HTTP Archive's 2024 Web Almanac shows 48% of mobile origins pass all three CWV. The other 52% are leaving rankings to faster competitors.[3]
Real-user data from Chrome User Experience Report (CrUX) feeds the signal. Lab scores from Lighthouse only approximate it.

If your engineering team has spent six months "improving performance" and your CrUX scores haven't moved, the work isn't reaching real users. That's the gap this playbook closes. For a wider technical lens, see our technical SEO audit for AI Overviews.

The 3 Metrics That Count

Three numbers. Each one ties to a specific user moment.

LCP (Largest Contentful Paint): when the largest visible element finishes rendering. Threshold: under 2.5s = good, under 4s = needs improvement, over 4s = poor.
INP (Interaction to Next Paint): the longest delay between a user action (click, tap, key press) and the next visual update. Threshold: under 200ms = good, under 500ms = needs improvement.
CLS (Cumulative Layout Shift): the sum of unexpected layout shifts during the page's lifetime. Threshold: under 0.1 = good, under 0.25 = needs improvement.

Google measures all three through CrUX, the 28-day rolling field dataset from real Chrome users who opt in. PageSpeed Insights and Search Console pull from the same source. Lighthouse runs synthetic tests in a lab. The lab number predicts. The field number ranks.

LCP Fixes That Actually Move Scores

LCP is usually the hero image, the H1 background, or the first paragraph of text. Four fixes, ranked by leverage.

Preload the LCP image. Add <link rel="preload" as="image" href="..." fetchpriority="high"> in the document head. On a Next.js site, set priority on the hero <Image>. We've seen LCP drop 800ms to 1.4s from this single change.
Self-host critical fonts with font-display: swap. Google Fonts via CDN adds DNS lookup and TLS overhead. Self-host the two or three weights you actually use, preload the WOFF2, and serve from the same origin.
Cut server response time (TTFB) under 600ms. Cache HTML at the edge. Use Vercel, Cloudflare, or Fastly. Database queries on every request kill TTFB. Pre-render or ISR every page that can be cached.
Inline critical CSS, defer the rest. Above-the-fold styles inline in <head>. Everything else loads via <link rel="stylesheet" media="print" onload="this.media='all'">.

Skip lazy-loading the LCP element. That's a common reflex that makes scores worse, not better.

INP Fixes Most Teams Miss

INP is the metric that surprises teams. A site can have a clean LCP and still fail INP because of one slow click handler.

Break up long tasks. Any JavaScript task over 50ms blocks the main thread. Split heavy work with scheduler.yield() or setTimeout(fn, 0). React 18's useTransition and useDeferredValue move non-urgent updates off the critical path.
Lazy-load third-party scripts. Intercom, HubSpot, Drift, Segment, and full-page analytics tags routinely add 300ms to INP. Load them after first interaction with Next.js <Script strategy="lazyOnload"> or Partytown.
Debounce input handlers. Search-as-you-type without debouncing fires a re-render on every keystroke. Wrap in a 150ms debounce. Same for resize, scroll, and mouse-move listeners.
Code-split heavy JavaScript. Charting libraries, rich text editors, and PDF viewers should load only on the route that needs them. Use dynamic imports. A 400KB bundle on the homepage that's used on 3% of sessions is dead weight.

INP failures on mobile are often hidden by fast desktop testing. Always check the mobile field score in PageSpeed Insights, not the lab score.

CLS Fixes That Stop the Page From Jumping

CLS is the easiest to fix and the easiest to ignore. Three items handle 90% of cases.

Reserve space for every image, iframe, and video. Add explicit width and height attributes (or aspect-ratio in CSS). Modern browsers compute the placeholder before the asset loads.
Match the swap font's metrics to the fallback. Use size-adjust, ascent-override, and descent-override on @font-face. The Fontaine library automates this. Pair with font-display: swap so text shows immediately.
Reserve space for ads and embeds. Ad slots and social embeds inject after page load and push content. Set a minimum min-height on the container. If the ad doesn't fill, the space is whitespace, not a shift.

Cookie banners that appear after 200ms are a common CLS killer. Either pre-render the banner space or position it as an overlay that doesn't affect layout.

The Toolchain

Five tools cover field, lab, and continuous monitoring. Use them in this order.

PageSpeed Insights (pagespeed.web.dev): single-page check, gives both field (CrUX) and lab (Lighthouse) scores. Use this first.
Lighthouse (built into Chrome DevTools): lab audit with actionable diagnostics. Use to debug a specific page after PSI flags it.
web.dev/measure: same Lighthouse engine, but with prioritized fix recommendations and learning paths.
Chrome User Experience Report (CrUX): the raw field dataset. Query through the CrUX API or BigQuery for site-wide trends.
Real-user monitoring (RUM): Vercel Speed Insights, Cloudflare Web Analytics, SpeedCurve, or Datadog. RUM catches regressions before CrUX's 28-day rolling window does.

Search Console's Core Web Vitals report sits on top of CrUX. It's the only place to see which URL groups (templates) are failing, not just which pages. Fix templates, not pages.

How to Run a 30-Day CWV Sprint

Three weeks of fixes, one week to validate. Output: every template moves to "good" or "needs improvement" downgrades to "good."

Week 1. Run PSI on the top 20 URLs by organic traffic. Group results by template (homepage, blog post, product page, location page). Identify the one slowest template.
Week 2. Fix the slowest template. Apply the LCP fixes first (highest leverage), then INP, then CLS.
Week 3. Move to the next two templates. Validate Week 2 fixes in Lighthouse, then watch CrUX for 14 days.
Week 4. Set up RUM. Add a regression alert if any vital crosses the threshold for 5% of sessions over a 7-day window.

Performance work that doesn't move CrUX in 30 days is either targeting the wrong template or the wrong metric. If you've been at it longer with no movement, our SEO audits team can diagnose where the field data and lab data are diverging.

When Performance Is a Platform Problem, Not a Code Problem

Some sites can't pass Core Web Vitals without a rebuild. The tell is usually one of three things.

WordPress theme with 40+ plugins, none lazy-loaded.
Shopify storefront with 12 third-party apps injecting render-blocking scripts.
Custom React SPA with no server-side rendering and no edge caching.

If your LCP is 5+ seconds on a content page and you've already applied image, font, and TTFB fixes, the platform is the bottleneck. Migrating to Next.js on Vercel typically moves LCP from 4-6s to under 2s and INP from 400ms to under 150ms. That's a website development conversation, not a performance tuning one.

The Bottom Line

LCP under 2.5s, INP under 200ms, CLS under 0.1, measured at the 75th percentile of real users.
Fix templates, not individual pages.
Field data (CrUX) is what ranks. Lab data (Lighthouse) is how you debug.
INP is the metric that surprises most teams in 2026. Audit third-party scripts first.
If 30 days of fixes don't move CrUX, the platform is the bottleneck, not the code.

Core Web Vitals are a hygiene factor. They don't win you rankings on their own. They keep the pages you do rank from quietly slipping. Audit, fix, monitor. Don't let a 3-second LCP undo six months of content work. Teams that ship CWV fixes alongside content publishing compound faster than teams that treat performance as a quarterly project. For ongoing performance and SEO execution under one team, see managed growth. And if performance is bleeding conversion on top of rankings, the CRO breakdown of where revenue leaks covers the conversion side of the same problem.