INP — Interaction to Next Paint — is the Core Web Vital that measures how responsive a page feels when a user clicks, taps, or types. Specifically, it captures the longest delay between any user interaction and the browser repainting the screen in response, across the full visit. Google's 'good' threshold is 200 milliseconds or less; 'poor' starts at 500 ms. INP replaced the older First Input Delay metric in March 2024 because FID only measured the very first interaction, missing the laggy scrolls and stuttered taps that happen later. INP is harder to game than LCP — it reflects what the main-thread JavaScript is actually doing when the user is actively trying to use the page. The worst offenders are large Single Page Applications that block the main thread with heavy re-renders, and sites loaded down with third-party scripts that steal CPU from every click.
What instant actually feels like
Every interaction on this site is effectively instant — no client-side routing, no hydration stall, no analytics library blocking the main thread. INP sits well under 100 ms in real-user data. A typical Wix site on a mid-range Android hits INP around 400 to 600 ms because the platform's SPA runtime, ad scripts, and editor-mode compatibility code all fight for the same main thread. The difference is not subtle — on Wix you can feel every tap wait its turn.
Why INP is the metric users actually notice
INP is the metric that captures 'this site feels slow' even when it loaded fast. A page with a good LCP but a bad INP looks great in the first second, then stutters every time the user tries to do anything. For forms, checkouts, and booking flows, that stutter costs conversions. It also makes the site feel cheap — which for a small business trying to look credible is the worst signal of all, because it plays every time a prospect touches the page.
Related terms
Bespoke, live in seven days.
£1,000 flat. Paid upfront. Full refund if I miss day seven. Code, hosting, and domain all in your name.