Google made the switch official today. Interaction to Next Paint — INP — has replaced First Input Delay as a Core Web Vital. FID is gone. Every site that has been tracking Core Web Vitals through Search Console, PageSpeed Insights, or any of the third-party monitoring tools is going to see new numbers as of this morning, and many of them are going to look worse than the FID numbers they replaced.
This is not a failure on those sites. INP measures something FID did not. The metric is harder to pass. The conversation about what ‘fast enough’ looks like has to shift.
What INP measures
FID measured only the first interaction on a page — the click, tap, or keypress that happened before the page was fully ready. It captured a single moment per page session. If the first interaction was fast, the FID number was good, regardless of what happened after.
INP measures the worst interaction across the entire page session. Every click. Every tap. Every keystroke. The metric records the time between the user action and the browser repainting the response. The worst of those response times — or specifically, a high percentile of them — is the INP score.
The threshold for ‘good’ is 200 milliseconds. Above 500 milliseconds is ‘poor.’ Anywhere in between is ‘needs improvement.’
Why most sites look worse on the new metric
FID was relatively easy to pass because the first interaction usually happens late in the page lifecycle, after most of the heavy initial JavaScript has finished executing. The browser has typically settled down by the time the user clicks anything. So FID rarely caught the real problem.
INP catches the real problem. It catches the click on a filter that triggers a heavy JavaScript handler. It catches the dropdown that runs a slow event listener. It catches the search input that performs a synchronous filter against five thousand items in memory. These are interactions FID never measured.
For sites that use heavyweight JavaScript frameworks, dense client-side filtering, or third-party widgets that hook into every click — INP is going to show numbers that FID hid.
Where INP gets bad
The places we have seen INP problems on real client sites:
Filterable product listings on e-commerce sites where filtering re-renders the entire grid. A single filter click can run 400 to 1200 milliseconds of JavaScript on a mid-range Android device.
Mega-menus that lazy-load their content on hover. The hover handler measures the menu bounds, runs the lazy-load, and reflows the layout. INP picks up the full duration.
Search inputs that synchronously filter long autocomplete lists. The keypress fires, the filter runs in the main thread, the result list re-renders. On a list of 500+ items the keystroke can take 250 to 500 milliseconds per character.
Third-party tags that hook into click events globally. Some analytics tags add 50 to 200 milliseconds of overhead to every click for tracking purposes. Stacked with other handlers, this is enough to push interactions into the ‘needs improvement’ bucket.
Modal openers that compute layout synchronously. A modal that calculates its size based on viewport math, builds its DOM in JavaScript, and runs animations on the main thread can easily be a 300 to 600 millisecond interaction.
The fix is structural
INP fixes are almost never one-line CSS additions. They are structural changes to how JavaScript runs.
The pattern that works most consistently:
- Identify the worst interactions through real user monitoring. The Chrome User Experience Report and tools like SpeedCurve or DebugBear show INP per interaction. Find the top three.
- For each one, profile the click in DevTools’ Performance panel. Find the long task. The fix is almost always in that long task.
- Move the work off the main thread, defer it, or split it. A 400-millisecond synchronous filter operation might become a 20-millisecond UI update followed by a deferred render of the actual results.
- Use scheduler.yield() or requestIdleCallback() to break long synchronous work into chunks. The browser can paint between chunks. The user sees a response immediately, even if the full result takes longer.
The React and Vue problem
Sites built on heavy client-side rendering frameworks — particularly older React or Vue applications without concurrent features — tend to have INP scores that are harder to fix than the equivalent server-rendered sites. The cost of re-rendering large component trees on every state change shows up directly in the metric.
For React, the fix path is usually upgrading to a version that supports concurrent rendering and using transitions for non-urgent updates. For Vue, the equivalent is using v-memo or breaking up monolithic components.
For WordPress sites running on Gutenberg, the front-end implications are minor because most Gutenberg block output is static HTML. The INP problem on WordPress sites comes from third-party plugins and themes that add their own JavaScript, not from core.
The Shopify problem
Shopify themes have an INP problem that is specific to the platform. Theme apps inject scripts globally. Cart drawer apps hook into every Add to Cart click. Subscription apps interpose on the checkout button. Each app adds 30 to 150 milliseconds of handler time.
The cumulative effect on a heavily-apped store is that every interaction is slow, even when no single app is doing anything obviously wrong. Auditing the app stack — disabling apps temporarily, measuring the difference, deciding which ones earn their cost — is the most reliable INP fix on Shopify.
What changes for site owners today
The Search Console Core Web Vitals report now shows INP instead of FID. Sites that were green on FID may be yellow or red on INP. The pages that were already passing are likely fine. The pages that are doing significant client-side work are the ones that need attention.
For most sites, INP is a ‘budget some time over the next quarter’ problem, not an emergency. Google has not announced any ranking penalty that did not already exist with FID. The metric is the same Core Web Vital. The threshold is different.
For sites where Core Web Vitals materially affect search performance — content sites in competitive niches, in particular — INP becomes the new optimization target. The performance audits we run now lead with INP, with LCP and CLS as the secondary metrics. The order of attention has flipped.