Web performance
Core Web Vitals in 2025: INP, thresholds, and fixes
INP replaced FID in March 2024. Here is what that means for your site, what the current thresholds are, and where performance typically breaks down.
TL;DR
- Google officially replaced First Input Delay (FID) with Interaction to Next Paint (INP) as a Core Web Vital in March 2024. FID is no longer a ranking signal.
- The three current Core Web Vitals are: Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). All three are used as ranking signals.
- Good thresholds: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Hitting good on all three matters for ranking and user experience.
- INP measures the worst-case interaction delay across the entire page visit, not just the first interaction. This makes it harder to pass than FID, which only measured the first click.
- See how we approach website performance for business-critical sites, and our performance budget guide for the enforcement layer.
Why INP replaced FID
FID measured the wrong thing. INP measures <em>every interaction</em>.
First Input Delay measured how long it took for the browser to respond to the first user interaction on a page (typically the first click or tap). The problem with FID was that it only captured that single first event. A page that loaded well, passed FID, and then became unresponsive when a user scrolled and clicked deeper into the content could still score "good" on FID even though the user experience was actually poor.
Interaction to Next Paint measures the delay between any user interaction (click, tap, keyboard input) and when the browser paints the next frame in response. It records all interactions across the page visit and reports the worst-case result. **A page must maintain responsive interactions throughout the entire session, not just on the first tap, to pass INP.**
For most production sites that had been optimised for FID, INP revealed new failure modes: third-party scripts firing during scroll, heavy JavaScript triggered by filter clicks, cart updates with long processing chains. FID hid these because they happened after the first interaction. INP surfaces them.
The three metrics
Good, needs improvement, and poor thresholds for each Core Web Vital.
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Time until the largest visible element (image or text block) loads | Under 2.5 s | 2.5 s to 4.0 s | Over 4.0 s |
| INP (Interaction to Next Paint) | Worst-case delay between a user interaction and the next frame painted | Under 200 ms | 200 ms to 500 ms | Over 500 ms |
| CLS (Cumulative Layout Shift) | Total unexpected visual movement of elements during page load and use | Under 0.1 | 0.1 to 0.25 | Over 0.25 |
Common failure points
Where Core Web Vitals break down most often.
01
Long main-thread tasks blocking INP
The most common cause of poor INP is a long JavaScript task running on the main thread when the user tries to interact. When the main thread is busy (parsing JavaScript, running a large event handler, updating a complex React tree), the browser cannot paint the response to a click until the task finishes. The fix is to break long tasks into smaller chunks, defer non-critical JavaScript, and use web workers for computation that does not touch the DOM.
02
Third-party scripts degrading LCP and INP
Tag managers, analytics, chat widgets, A/B testing scripts, and ad tech are the most common sources of performance degradation for sites that pass Core Web Vitals in lab testing but fail in field data. These scripts fire on real user sessions, compete for main-thread time, and often load more scripts asynchronously after the initial load. Loading third-party scripts with appropriate defer/async attributes, lazy-loading non-essential widgets, and auditing what your tag manager actually fires is the starting point.
03
Unoptimised images causing LCP failures
The Largest Contentful Paint element is most often a hero image or a product image above the fold. Common LCP failures: the image is not preloaded (no <link rel="preload">), it is served in JPEG or PNG instead of WebP or AVIF, it is sized for desktop on mobile viewports, or it sits behind a lazy-load attribute that delays its fetch. For any image that is the LCP candidate on most sessions, eager loading, modern format, and correct sizing are non-negotiable.
04
Layout shifts from late-loading fonts and injected content
Cumulative Layout Shift failures are usually caused by one of three things: fonts that swap in after the initial text render (causing a text reflow), images without explicit width and height attributes (causing the browser to recalculate layout when they load), or content injected above the fold by ads, cookie banners, or dynamic personalisation. The fixes are specific to each cause: font-display: optional or swap with preloading for fonts, explicit dimensions for images, and reserved space for injected content.
Common questions
What teams ask when they start a Core Web Vitals improvement project.
Does Google actually use Core Web Vitals as a ranking factor?
Yes. Google confirmed Core Web Vitals as a ranking signal in the Page Experience update (2021). The weight of the signal relative to content relevance is not disclosed, but Google has made clear that page experience (including Core Web Vitals) contributes to ranking decisions. Practically: for two pages of similar topical relevance, the one with better Core Web Vitals will tend to rank higher. For a weak page on a competitive query, good Core Web Vitals will not rescue it.
My Lighthouse score is good but my CrUX data is bad. Why?
Lighthouse measures under controlled lab conditions: a single headless Chrome instance, no third-party scripts that require authentication, no tag manager firing, clean network. CrUX (Chrome User Experience Report) captures real user sessions: slow devices, variable network conditions, third-party scripts firing, user sessions that trigger heavy interactions. Lab tools tell you what is possible. Field data tells you what users actually experience. Both are necessary; field data is what Google uses for ranking.
We are on WordPress. What is most likely to be causing poor Core Web Vitals?
For WordPress sites, the most common causes in order of frequency: a hero image that is not preloaded or served in modern format (LCP), a page builder generating excessive DOM and CSS (LCP and INP), a tag manager firing multiple third-party scripts on page load (INP), and a cookie consent banner that shifts content when it appears (CLS). A performance audit that measures LCP element, long tasks, and cumulative layout shift sources will identify the priority items for your specific site.
How much does fixing Core Web Vitals improve SEO?
The direct SEO impact depends on how competitive the keywords are and how significant the gap is between your site and competitors. In competitive niches where multiple pages have similar content, improving from "needs improvement" to "good" on Core Web Vitals can produce a measurable ranking lift, typically within three to eight weeks as Google re-crawls and re-evaluates the page. The conversion impact of better performance is often larger and more immediate than the SEO impact.
What replaced FID in tools and reports?
INP replaced FID as a Core Web Vital in March 2024. In the Chrome User Experience Report (CrUX), INP data replaced FID data. In Google Search Console, the Core Web Vitals report now shows INP instead of FID. In Lighthouse, INP appears in the performance diagnostics section. In field measurement tools like web-vitals.js, the INP metric replaces FID in the event handler. Any performance report still showing FID as a Core Web Vital is using outdated data.
Is a good INP score possible with a complex single-page app?
Yes, but it requires deliberate architecture. React-heavy SPAs are among the most common sources of poor INP because large component re-renders block the main thread during interactions. The fixes: use concurrent rendering features (React 18 transitions), break large components into smaller, memoised units, move heavy computation to web workers, and profile interactions in Chrome DevTools to identify the specific long task. Good INP on a complex SPA is achievable; it requires performance to be a design constraint, not a retrofit.
How we approach Core Web Vitals
Field data first, then targeted fixes, then a budget to prevent regression.
We start with field data, not Lighthouse. CrUX data shows what real users on your actual pages experience. We identify the specific LCP element, the interactions causing high INP, and the sources of layout shift before touching any code. That gives us a priority list where the top three items typically account for 80% of the performance gap. **See how we approach website performance for sites where performance is a business metric, not a vanity score.**
After fixes are deployed, we set a performance budget: automated checks that run after each deployment and block a release if Core Web Vitals regress. A budget is the only reliable way to prevent a site from getting slower again as new features are added. See the performance budget guide for how to set one up.
Concrete solution
Bring the operational risk.You get a clear diagnosis and a concrete next step.
We are the right fit if you want a team that pushes back when it matters. See outcomes and metrics →
Reviewing first?
Company evidenceon the site.
Engagements with commercial outcomes on Work. Team bios and operating model on About. Nothing to download. Review it before you commit to a call. Open to review. Commit when ready.