Core Web Vitals & INP 2026

In March 2024, Google officially introduced Interaction to Next Paint (INP) as a Core Web Vital, replacing First Input Delay (FID). At first glance, this sounds like a technical footnote — it is not. FID only measured the delay until the browser first processed an input, while ignoring how long it took for anything to visually update on screen. INP captures precisely that: the full latency from a user's click to a visible response, measured across all interactions in a session, not just the first one.

For decision-makers in mid-market B2B businesses, this change has two direct consequences. First, pages that appeared clean under FID can score significantly worse under INP — because they respond quickly to the first tap but stall on subsequent interactions such as form entries, filter actions, or tab switches. Second, Google uses INP as a ranking signal in the Page Experience update. A poor INP score can cost positions even when LCP and CLS are in the green.

From my work with B2B websites, I regularly observe that JavaScript-heavy platforms — particularly React and Next.js setups with substantial client-side rendering — are structurally disadvantaged on INP unless specific architectural decisions are made deliberately. This is not an argument against modern frameworks, but an argument for prioritising performance from the outset.

Core Web Vitals are not an academic exercise. They model three concrete user experiences: how quickly does the most important content become visible, how responsive does the page feel during interaction, and how stable is the layout while it loads? These three dimensions — loading speed, interactivity, and visual stability — correlate demonstrably with bounce rate, session duration, and conversion.

Largest Contentful Paint (LCP) measures the time to render the largest visible content element, typically a hero image or an H1. The threshold for 'good' is 2.5 seconds. Common causes of poor LCP: uncompressed images, missing preload hints for critical resources, slow server response times (TTFB), and render-blocking JavaScript.

Cumulative Layout Shift (CLS) quantifies unexpected layout shifts — when elements jump during loading and users accidentally tap the wrong button. The threshold is 0.1. Common causes: images without explicit dimensions, banners inserted after initial render, and web fonts loaded without a font-display strategy.

Interaction to Next Paint (INP) is the new key metric. Good means under 200 ms, needs improvement falls between 200 and 500 ms, and poor is above 500 ms. INP measures the latency from user input to the next rendered frame — across all interactions in the session, with the 98th percentile value serving as the overall score. This makes INP more sensitive to rare but severe slowdowns than FID ever was.

The distinction between field and lab data is central to practical optimisation work. Lab data comes from controlled measurement environments — Lighthouse, WebPageTest, PageSpeed Insights in lab mode. It is reproducible, well suited for regression testing, and provides detailed traces. But it simulates a single page load on a defined device under defined network conditions.

Field data, by contrast, comes from the Chrome User Experience Report (CrUX) — aggregated, anonymised measurements from real user sessions. It reflects the actual experience of your audience: with their devices, connections, and usage patterns. For Google's ranking algorithm, only the field data signal counts. Lighthouse scores do not automatically translate into ranking improvements unless the CrUX data follows.

INP is by definition a field metric: lab tools cannot capture real interaction sequences across a complete user session. Lighthouse does measure Total Blocking Time (TBT) as a lab proxy — an indicator of long tasks that can worsen INP — but TBT and INP are not equivalent. A low TBT does not guarantee a good INP.

The practical implication: INP optimisation requires Real User Monitoring (RUM). Google Search Console shows CrUX-based INP values at URL level. For deeper diagnostics, tools such as SpeedCurve, Sentry Performance, or the Web Vitals JavaScript snippet embedded directly in your analytics stack are appropriate. Only when you know which interactions on which pages affect which user groups can you intervene effectively.

INP problems rarely stem from a single cause. In practice, it is usually several overlapping factors that together cause the browser to take hundreds of milliseconds after a click before anything changes on screen. The three most common cause clusters are: long tasks on the main thread, hydration overhead in server-side-rendered frameworks, and inefficient event handlers.

Long tasks are JavaScript blocks that block the main thread for longer than 50 ms. While a long task is running, the browser can neither respond to user input nor render new frames. The result: the user clicks, sees nothing happen, clicks again — and the backed-up interaction queue extends the measured INP further. Long tasks are visible in the Chrome DevTools Performance panel as red blocks, explicitly labelled as 'Long Tasks'.

Hydration is the specific problem of frameworks such as Next.js, Nuxt, or SvelteKit in SSR/SSG mode: the page is initially served as static HTML (good for LCP), then JavaScript loads and 'hydrates' the static page into an interactive app. During this hydration phase the page is visible to users, but interactions can cause dramatic INP spikes because the hydration process blocks the main thread. Progressive hydration, island architecture (e.g. Astro), and React Server Components are architectural responses to this problem.

Inefficient event handlers are the most consistently underestimated cause. Every time a user clicks or types, the associated event handler runs synchronously. If that handler triggers complex DOM operations, synchronous data fetches, or cascading state updates, the time to the next paint increases directly. Particularly critical: event handlers that cause layout thrashing — alternately reading and writing to the DOM, forcing the browser to recalculate layout repeatedly.

Performance optimisation without prioritisation is a waste of resources. The following framework describes a structured path from the first measurement to a productive improvement — with a clear focus on the measures with the greatest impact for acceptable effort.

Step 1 — Baseline diagnostics: Open Google Search Console, navigate to 'Core Web Vitals'. Which URLs have 'poor' INP values? Are these templates (e.g. all product pages) or individual pages? These URL clusters define the scope of optimisation. In parallel, check CrUX data via PageSpeed Insights at page level to understand device and connection splits.

Step 2 — Interaction tracing: Chrome DevTools, Performance panel, record during a typical user session on the problematic page. Specifically: click on the most common interaction (CTA button, filter, form field), then analyse the trace. How long is the input-to-paint latency? Which code block causes the longest task? The Performance panel shows long tasks, scripting overhead, and layout operations in a waterfall view.

Step 3 — Prioritise measures by category: Code splitting for JavaScript bundles reduces hydration load. Delegate third-party scripts to a Web Worker or offload them via Partytown. Split event handlers using requestAnimationFrame or the Scheduler API (scheduler.yield()) so the browser can process interactions between tasks. For React/Next.js: use startTransition() for non-urgent state updates to maintain visual responsiveness.

Step 4 — Validate in staging: After each change, measure TBT in Lighthouse as a proxy and repeat DevTools traces. No deploy without measurable proof of improvement in the lab. Staging data does not replace field data, but it prevents regressions.

Step 5 — Field data monitoring: Set up RUM (or extend your existing analytics setup to include Web Vitals). Wait at least 28 days for CrUX data to reflect the improvement — Google updates CrUX on a rolling basis over this period. Only then is the optimisation cycle complete.

The question that comes up in every conversation with marketing leads: 'What does this actually deliver?' The honest answer is nuanced. Core Web Vitals are a confirmed ranking signal in Google's Page Experience update, but they are not a dominant signal. Relevance, backlinks, and content quality continue to carry more weight. What Vitals do: they act as a tiebreaker between otherwise comparable pages and as a minimum standard below which even high-quality content can be disadvantaged.

The business relevance of INP lies less in the ranking algorithm, however, and more in its direct effect on user behaviour. Google's own research indicates that improving Core Web Vitals by one tier (e.g. from 'poor' to 'needs improvement') can have measurable effects on bounce rate and session duration. Amazon, Pinterest, and others have documented in internal tests that loading time improvements in the millisecond range affected conversion — though at traffic volumes that mid-market B2B websites typically do not reach.

What I can report from concrete projects: B2B websites with poor Core Web Vitals do not lose rankings overnight, but they accumulate a structural disadvantage over time compared to competitors who actively optimise. And the direct user effect is real: a page that takes 600 ms to respond to a click generates measurable friction — especially on forms, checkout flows, and interactive tools. This is not a conversion value visible in an A/B test within two weeks, but it is cumulatively significant.

For strategic prioritisation I apply this framework: if Core Web Vitals are in the 'poor' range, optimisation is not an optional measure but a hygiene requirement. If they are in the 'needs improvement' range, I first check whether INP spikes occur on conversion-critical interactions. If so, the business case is clear. If all three Vitals are in the green, attention shifts to other levers.

The following sources form the basis of the technical facts and thresholds presented in this article.