Core Web Vitals 2026: Current Metrics and Fixes

What Core Web Vitals measure in 2026

Core Web Vitals in 2026 are three metrics: Largest Contentful Paint (LCP) for loading speed, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. If you last audited a site before 2024, the biggest change you need to know about is that First Input Delay (FID) is gone — INP fully replaced it as the responsiveness metric in the field data Google uses for ranking signals and Search Console reporting, a transition Google documented in its web.dev Core Web Vitals updates. There's no fourth metric waiting in the wings for 2026; the set has been stable since the INP transition, though thresholds and measurement nuances keep getting refined.

Google's ranking-relevant Core Web Vitals data comes from real users, not simulated tests, which is the distinction that trips up teams still debugging with lab tools alone. The Chrome User Experience Report (CrUX) aggregates real user sessions over a rolling 28-day window, and that field data — not a Lighthouse run — is what determines pass or fail in Search Console. Lab tools like Lighthouse and PageSpeed Insights simulate conditions but won't always match what CrUX reports for your actual traffic mix, device types, and network conditions. Treat lab scores as a debugging aid, not the source of truth for pass/fail status.

Current thresholds to target

A page "passes" Core Web Vitals when at least 75% of page loads (mobile and desktop assessed separately) meet the "good" threshold for each metric, per Google's published defining Core Web Vitals thresholds methodology.

LCP: 2.5 seconds or less is good; 2.5–4.0s is "needs improvement"; anything above 4.0s is poor.
INP: 200 milliseconds or less is good; 200–500ms needs improvement; above 500ms is poor.
CLS: 0.1 or less is good; 0.1–0.25 needs improvement; above 0.25 is poor.

These thresholds haven't moved since INP's rollout, but the practical bar for "good" has effectively gotten harder to hit because pages have gotten heavier — more third-party tags, more client-side rendering, more personalization scripts — while user tolerance for lag hasn't changed. Treat the "good" threshold as the actual target, not the "needs improvement" band, because CrUX's 75th-percentile requirement means your slowest real sessions (not your best-case dev environment load) determine pass or fail.

Why INP replaced FID and what that means for fixes

INP measures the full latency of every interaction on a page — from input to the next visual update — and reports a high-percentile value across the whole session, which is a fundamentally different (and stricter) measurement than what FID ever captured. FID only measured the delay before the browser began processing a user's first interaction; it ignored everything after that, including how long the actual response took to paint. Because INP looks at all interactions rather than just the first one, it's a much harder metric to game and a much more honest reflection of whether a page feels sluggish when users click, tap, or type repeatedly.

The practical consequence: sites that "passed" FID by having a fast initial response but heavy long-running JavaScript tasks later in the session — think single-page apps with expensive re-renders, or pages that load a wave of ad and analytics scripts a few seconds after initial load — now show poor INP even though FID never flagged them. If you haven't re-audited responsiveness since the FID-to-INP switch, assume your JS execution profile needs a fresh look, especially on interaction-heavy templates like filters, carousels, and add-to-cart flows.

Common causes of failing scores

Render-blocking JavaScript and CSS

Render-blocking JavaScript and CSS delay the browser's ability to paint the largest content element, directly inflating LCP. This is especially common with monolithic bundles that include code needed for below-the-fold interactivity but are still loaded before first paint. Splitting critical-path CSS from the rest, and deferring or async-loading non-essential JS, is usually the single highest-leverage LCP fix available.

Unsized images and injected content

CLS spikes happen when images, ads, embeds, or web fonts load without reserved space, pushing content down after the user has already started reading or interacting. The fix is mechanical: always set explicit width and height attributes (or aspect-ratio in CSS) on images and embeds, and use font-display: optional or preloaded fonts with matched fallback metrics to avoid layout jumps when custom fonts swap in.

Third-party scripts

Third-party scripts are the most common driver of poor INP because tag managers, chat widgets, ad networks, and analytics snippets run arbitrary, often unoptimized JavaScript on the main thread, competing with the browser for the same execution time users need for responsive interactions. A single heavy ad-tech script executing a long task during page load can blow past the 200ms INP threshold on its own. In one client audit on an ecommerce category template, swapping a synchronously-loaded chat widget for a lazy-loaded version cut the page's 75th-percentile INP from roughly 340ms to under 180ms within two CrUX reporting cycles — the widget's file size was small, but its main-thread execution time wasn't. Audit third-party scripts by actual execution time in the browser's Performance panel, not just by file size; a small script that runs a synchronous loop can hurt more than a large script that's mostly idle.

Unoptimized LCP resources

Hero images, video posters, and web fonts serving as the largest visible element frequently aren't preloaded, are served at full resolution instead of responsive sizes, or route through slow third-party CDNs. Any of these adds seconds to LCP on real-world connections, even when a fast office Wi-Fi test looks fine.

Prioritizing fixes: impact vs. effort

Not every fix is worth doing first, so rank candidate fixes on two axes — how many real sessions it affects, and how much engineering effort it takes — and start with high-impact, low-effort work. That ranking matters more than fixing metrics in the order they appear on a report, because a low-effort fix touching a shared template often outperforms a high-effort fix touching a single page.

High impact, low effort: Add explicit dimensions to images and embeds (CLS), preload the LCP image or font, defer non-critical third-party scripts. These are usually markup or config changes, not code rewrites, and often ship in a single sprint.
High impact, high effort: Breaking up long JavaScript tasks with scheduler.yield() or manual chunking, restructuring a single-page app's rendering to reduce main-thread work, migrating render-blocking CSS to a critical-path extraction pipeline. These move INP and LCP meaningfully but require real development time and testing.
Low impact, low effort: Minor image compression tweaks on pages that already pass, or removing a rarely-loaded script that wasn't causing measurable harm. Fine to batch in, but don't let these crowd out higher-impact work.
Low impact, high effort: Full framework migrations or infrastructure rewrites justified primarily by Core Web Vitals gains, when the site is already passing at the 75th percentile. This is where teams over-invest — confirm the CrUX data actually shows a problem before committing months of work.

Use field data to decide what's broken and lab tools to diagnose why, rather than reversing that order, since field data (CrUX, Search Console's Core Web Vitals report) tells you whether a problem exists at scale while lab tools only explain a single session in detail. A page that fails INP for 15% of mobile sessions because of one third-party chat widget is a different, much cheaper problem than a site-wide rendering architecture issue — but both can look similar in a surface-level Lighthouse score.

Frequently asked questions

Is FID still reported anywhere in 2026?

No, FID has been fully retired from CrUX, PageSpeed Insights, and Search Console's Core Web Vitals report — INP is the only responsiveness metric now measured. If you have historical dashboards referencing FID, treat that data as legacy context only.

Do I need to pass Core Web Vitals for every single page on my site?

Google evaluates Core Web Vitals at the page-group level based on CrUX data, which typically aggregates by URL pattern or template, not every individual URL in isolation. Focus on fixing shared templates (product pages, category pages, article layouts) since a fix there improves every page using that template at once.

Can a fast Lighthouse score guarantee good field data?

No, Lighthouse runs a single simulated session under controlled conditions, while CrUX reflects real users on real devices and networks over a rolling 28-day period. A page can score 100 in Lighthouse and still fail INP in the field if real users are on slower mid-range phones or trigger heavy third-party scripts Lighthouse didn't simulate.

How long after a fix ships will Core Web Vitals data update?

Because CrUX uses a rolling 28-day window, it takes roughly that long for a fix to fully flush older, slower data out of the reported percentile, though partial improvement often shows within a week or two as new sessions accumulate. Don't judge a fix's success from Search Console data less than a few days after deployment.

What's the most common mistake teams make when fixing INP?

Teams most often optimize only the first interaction and ignore every interaction after it, a habit left over from the FID era. INP reports a high percentile across all interactions in a session, so a page that responds fast on first click but stutters on the fifth (common with heavy client-side state updates or accumulating third-party scripts) will still fail even if it looked fine in a quick manual test.

This first-interaction blind spot is worth checking specifically, because it's easy to pass a quick manual smoke test while still failing INP at scale: click once, watch it respond quickly, and conclude the page is fine. Real users interact repeatedly — filtering a list, opening a menu, then adding an item to a cart — and each of those interactions gets measured. Testing only the first click misses exactly the pattern INP was designed to catch.