Core Web Vitals are the subset of Google's page experience signals that measure real-world usability: how fast content loads, how stable the layout is while loading, and how quickly the page responds when someone actually uses it. They are not synthetic lab scores dreamed up by engineers with too much free time — they are built from field data collected via the Chrome User Experience Report (CrUX), which means they reflect what real visitors on real devices and real networks experience on your site.
Since March 2024, the three official Core Web Vitals are:
INP is the newest member of this trio, and it replaced First Input Delay (FID) as the official responsiveness metric. Understanding why that swap happened is the key to understanding why INP is harder to game and why it matters so much more for how your site actually feels to use.
FID had a fundamental blind spot: it only measured the delay before the browser started processing the very first interaction on a page. If a user clicked a button and the browser took 400ms to even begin handling that click, FID would flag it. But FID stopped measuring the moment processing began — it said nothing about how long the actual work took, and it said nothing about any interaction after the first one.
That meant a site could score a perfect FID while still being maddeningly unresponsive. A single-page app with a snappy first click but a laggy, JavaScript-choked "add to cart" button three interactions later would sail through FID and still frustrate every real user who tried to check out.
INP fixes this by observing every interaction during a page's lifecycle — clicks, taps, and key presses — and measuring the full duration from input to the next visual paint, including input delay, processing time, and presentation delay. It then reports (roughly) the worst interaction latency observed, discarding a small number of outliers on pages with many interactions. This gives Google, and you, a metric that reflects the interaction quality across the entire session rather than just the opening handshake.
In short: FID asked "did the browser notice you clicked?" INP asks "how long did it actually take before the screen caught up?" That is a much closer proxy for what users mean when they say a site feels "laggy" or "janky."
Google defines INP performance in three bands, measured at the 75th percentile of interactions across real users on a page or origin:
The 75th-percentile framing matters. It's not your best case, and it's not your average — it's the experience that three out of four visits do at least as well as. That makes INP unforgiving of intermittent jank: if a quarter of your sessions hit a 900ms interaction because of a heavy third-party script or a poorly memoized React re-render, your origin-level INP will reflect it even if most interactions feel instant.
Consider a fairly typical scenario for a growing SaaS product: an analytics dashboard with a sidebar filter panel, a data table, and a handful of chart widgets. LCP looked fine — under 1.8 seconds — because the shell rendered quickly and the hero chart above the fold painted early. CLS was clean too, since the layout was stable once loaded.
But the product team kept hearing the same complaint in support tickets and churn interviews: "the app feels sluggish." Nobody could point to a specific bug. The dashboard loaded fine. The problem only showed up when users actually interacted with it — applying a filter, sorting a column, or toggling a chart's date range.
A Core Web Vitals field report (pulled from the Chrome UX Report via PageSpeed Insights) showed the real story: INP at the 75th percentile was sitting around 640ms — solidly in the "poor" range. Digging into Chrome DevTools' Performance panel revealed the cause: every filter click triggered a synchronous re-render of the entire table component, ran an unmemoized sort function over the full dataset, and recalculated chart bounding boxes on the main thread — all before the browser could paint the next frame. On a mid-range laptop this was barely noticeable. On the Chromebooks and older machines a meaningful slice of the customer base actually used, it was a half-second freeze on every click.
After the team broke up that work (details in the next section), 75th-percentile INP dropped to 140ms. Two things happened that mattered to the business, not just the engineering team: organic search visibility for competitive dashboard-related keywords improved modestly over the following weeks as the page experience signal cleaned up, and — more significantly — the self-serve trial-to-paid conversion rate rose measurably, because fewer trial users abandoned the product during the exact moment they were evaluating whether it felt trustworthy and fast. Responsiveness isn't a cosmetic metric; for a product where the interaction is the pitch, it's close to the whole experience.
Fixing INP is fundamentally about reducing how much work the main thread does in response to user input, and making sure whatever work remains doesn't block rendering. Here's a practical sequence for tackling it.
Start with the Chrome User Experience Report data in PageSpeed Insights or the Core Web Vitals report in Google Search Console to see your real-world, 75th-percentile INP by page or page group. Then use the Performance panel in Chrome DevTools to record actual interactions locally and see exactly which scripts, event handlers, and style recalculations are eating time. The DevTools "Interactions" track since Chrome 118+ specifically breaks down input delay, processing time, and presentation delay for each recorded interaction — use it to know which of the three phases is actually your bottleneck before you optimize anything.
Any task that occupies the main thread for more than 50ms is a "long task" and is a prime suspect for blocking interaction responsiveness. Use PerformanceObserver with the longtask entry type, or the Long Tasks track in DevTools, to find them. Once found, break large synchronous functions into smaller chunks using techniques like scheduler.yield() (or setTimeout(fn, 0) as a fallback) so the browser gets a chance to paint and process other input between chunks, instead of running one monolithic function start to finish.
Audit what actually runs inside your click, input, and keydown handlers. Common culprits include unnecessary re-renders of large component trees, expensive DOM queries repeated on every keystroke, and business logic (validation, formatting, filtering) that could be debounced, memoized, or deferred until after the next paint. In React specifically, this is where useMemo, useCallback, and list virtualization earn their keep — a sort or filter over thousands of rows should never run synchronously inside the handler that fires on every click.
Anything that doesn't need direct DOM access — heavy calculations, data transformation, sorting large datasets, parsing JSON, image processing — is a candidate for a Web Worker. Moving that work off the main thread means it no longer competes with paint and input handling. Libraries like Comlink make the message-passing boilerplate much less painful if you're not used to working with workers directly.
A lot of INP pain isn't from one bad interaction — it's cumulative main-thread congestion from too much JavaScript parsing, compiling, and executing on every page. Route-based and component-based code-splitting (dynamic import(), React.lazy, or your framework's built-in equivalent) keeps the initial JS bundle lean and defers non-critical code until it's actually needed. Audit third-party scripts too — tag managers, chat widgets, and analytics snippets are frequent, invisible sources of long tasks that developers rarely profile because the offending code isn't in their own repo.
Reading a layout property (like offsetHeight or getBoundingClientRect()) immediately after writing to the DOM forces a synchronous reflow, and doing this in a loop is one of the most common causes of janky interactions. Batch DOM reads before DOM writes, use requestAnimationFrame for visual updates, and prefer CSS transforms and opacity changes over properties that trigger layout recalculation, since those can be handled on the compositor thread without blocking the main thread at all.
Once changes ship, re-check both lab data (DevTools, Lighthouse) and field data (PageSpeed Insights, CrUX) — lab tools tell you if a fix worked in a controlled environment, but only field data confirms it holds up across your real user base's actual devices and networks. Consider wiring INP tracking into your own real-user-monitoring setup (the web-vitals JavaScript library makes this straightforward) so regressions get caught before they show up three weeks later in Search Console.
Improving INP isn't a box-ticking exercise for a Lighthouse score — it pays off in three concrete ways.
At Mavani Solution, performance budgets — including INP thresholds — are treated as a first-class requirement in the web apps and SaaS products we build for startups and SMEs, not an afterthought bolted on after launch. It's far cheaper to architect for responsiveness from the start than to retrofit it into a codebase full of unmemoized components and monolithic event handlers.
INP is a stricter, more honest metric than FID ever was, because it measures what actually matters to users: not whether the browser noticed their first click, but whether the interface kept up with them throughout the entire session. Getting your 75th-percentile INP under 200ms takes real engineering discipline — profiling with DevTools, breaking up long tasks, moving heavy work off the main thread, code-splitting aggressively, and avoiding layout thrashing — but the payoff shows up in rankings, conversion rates, and the simple, hard-to-fake feeling that a product is well built. In 2026, responsiveness isn't a nice-to-have. It's a metric Google measures, users feel, and competitors are already optimizing for.