INP Explained: Why Your Site Feels Slow After It Loads

Fast to load, slow to use

You have probably seen it: the page appears quickly, you tap "Menu" or "Add to cart" — and nothing happens for a moment. Loading metrics look fine, but the site feels slow. That delay is exactly what Interaction to Next Paint (INP) measures.

On March 12, 2024, INP replaced First Input Delay (FID) as Google's Core Web Vital for responsiveness. FID only measured the delay before the browser started handling the first interaction. INP looks at the interactions throughout the visit and reports how long it took until the screen actually updated.

What a good score looks like

• 200 ms or less — good
• 200–500 ms — needs improvement
• over 500 ms — poor

Google evaluates the 75th percentile of real visits, separately for mobile and desktop. That means the experience of visitors on mid-range phones matters as much as your developer's fast laptop.

How to find the problem

• PageSpeed Insights and the Core Web Vitals report in Search Console show field data from real Chrome users — start there to see whether INP is a problem at all
• Chrome DevTools, Performance panel: record yourself clicking the slow element and look for long tasks on the main thread
• The web-vitals JavaScript library can report INP from your own visitors, including which element was involved

The usual causes — and fixes

Almost always, the browser's main thread is busy with JavaScript when the user interacts. A task longer than 50 ms is considered a "long task", and while it runs the page cannot respond.

• Break up long tasks. Do the visible update first, then yield to the browser and finish the rest of the work afterwards
• Audit third-party scripts. Chat widgets, tag managers, A/B testing and tracking pixels are frequent offenders; load them later or remove what nobody uses
• Keep the DOM lean. Huge pages with thousands of elements are expensive to re-render after every click
• In React, avoid re-rendering the whole page on every input; mark non-urgent updates with useTransition and memoise heavy components
• Debounce handlers for search fields and filters instead of recalculating on every keystroke

Why it is worth the effort

Core Web Vitals are part of Google's page experience signals, but the bigger reason is human: people repeat taps, abandon carts and assume the site is broken when it doesn't react. Responsiveness is something users feel directly.

The platform sets the starting point — compare WordPress and Next.js — and dynamic apps have their own search trade-offs, covered in SEO for dynamic web applications. We fix responsiveness as part of web application development and ongoing website support.

Is your site slow to respond? Codearia analyses Core Web Vitals and fixes performance problems in Next.js, React and WordPress sites — send us the URL.