Core Web Vitals 2026: Current Metrics, Thresholds, Fixes

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 window of recent traffic, 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. If your technical audits still lean on lab-only checks elsewhere, it's worth revisiting the fundamentals in our technical SEO basics primer.

Current thresholds to target

A page passes Core Web Vitals when the large majority of its page loads (mobile and desktop assessed separately) meet the "good" threshold for each metric, per Google's own defining Core Web Vitals thresholds methodology. The specific per-metric bands are:

• LCP: a low-seconds range counts as good, a middle band is "needs improvement," and anything well beyond that is poor.
• INP: a low-hundreds-of-milliseconds range counts as good, a middle band needs improvement, and anything well beyond that is poor.
• CLS: a small decimal score near zero counts as good, a middle band needs improvement, and a high score is poor.

These bands 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" band as the actual target, not the "needs improvement" band, because Google's percentile-based pass/fail requirement means your slowest real sessions, not your best-case dev environment load, determine whether a page passes.

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 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 a 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 push a page well past its INP target on its own. 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 meaningful delay 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.

1. 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.
2. 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.
3. 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.
4. Low impact, high effort: Full framework migrations or infrastructure rewrites justified primarily by Core Web Vitals gains, when the site is already passing. This is where teams over-invest — confirm the field 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 on a meaningful share 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. Teams working on larger sites should also weigh this against overall crawl efficiency; our guide to crawl budget optimization covers a related but distinct set of priorities that shouldn't get lost behind a Core Web Vitals push.

Fixing the render path often surfaces adjacent structural issues worth cleaning up in the same pass, since a template rewrite is a natural point to also audit markup quality. If your LCP fixes touch template head tags, it's a reasonable moment to check that structured data is implemented correctly at the same time, since both live in the same render-blocking region of the document and get touched by the same deploy.

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 field 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 reporting window. A page can score well 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 window rather than a single snapshot, it takes time for a fix to fully flush older, slower sessions out of the reported data, though partial improvement often shows well before the full window has cycled as new sessions accumulate. Don't judge a fix's success from Search Console data collected only 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.