INP explained: why your website feels laggy when people click

You click an accordion menu, tap a mobile navigation toggle, or press an add-to-cart button, and nothing happens for half a second. You tap again, wondering if the screen registered your finger. Suddenly, both actions fire at once, leaving you on the wrong view or looking at an unexpected state.

That laggy feeling is exactly what Google measures with Interaction to Next Paint (INP). While earlier web speed metrics focused mostly on how quickly text and pictures first appeared on screen, INP focuses entirely on how responsive your website feels once real people start interacting with it.

A site can look fully loaded in under two seconds but still freeze the moment someone clicks a button. When evaluating your site through a speed and Core Web Vitals fix, addressing INP is often the difference between a frustrating user interface and a seamless browsing experience.

What Interaction to Next Paint actually measures

INP tracks the latency of user interactions throughout the entire lifespan of a page visit. When someone clicks a link, taps a button on a phone, or types into an input field, the browser has to process that command and paint the updated pixels on the screen.

Google assesses the longest interactions on a page visit, ignoring rare outliers, to score your page. According to Google's official Core Web Vitals thresholds, an INP value of 200 milliseconds or less means good responsiveness. Between 200 and 500 milliseconds needs improvement, and anything above 500 milliseconds is rated poor.

An interaction is broken into three phases: input delay (the time the browser waits before it can start running your code), processing time (the time your JavaScript functions take to execute), and presentation delay (the time the browser takes to recalculate styles and paint the new frame).

The main reason clicks freeze: main thread blockage

Browsers run JavaScript on a single thread. That single thread is responsible for handling network calls, running scripts, calculating layout geometry, and painting pixels to your monitor or phone display. If that thread is busy executing a large script, it cannot stop mid-calculation to acknowledge a button tap.

This is why a site feels frozen. Your click event enters a queue, waiting patiently behind whatever intensive task the browser is currently running. Until that running task completes, the browser cannot display visual feedback, such as an active button state or an open navigation panel.

In modern web development, these delays usually stem from third-party tracking scripts, large JavaScript bundles, or unoptimized framework re-renders that fire on every small event.

Common causes of poor INP scores

In my projects, when I audit a site struggling with interaction latency, the issues almost always trace back to a few familiar architectural bottlenecks.

Marketing teams often install analytics tools, chat widgets, heatmaps, and remarketing tags through a single tag manager. Each snippet injects JavaScript that executes on the main thread, often running continuously in the background and delaying user input.

Similarly, frontend frameworks like React can suffer from unnecessary re-renders. If clicking an input field in a contact form causes the entire page tree and header navigation to re-render, the browser spends hundreds of milliseconds calculating differences instead of showing the typed character.

• Heavy third-party marketing tags and chat widgets loading synchronously.
• Oversized JavaScript bundles that take hundreds of milliseconds to parse and evaluate.
• Complex DOM structures where updating a single element triggers expensive layout recalculations across thousands of nodes.
• Expensive event listeners attached to scroll, resize, or input events without throttling or debouncing.

How to fix interaction delays on your site

Fixing INP requires reducing the work the browser has to do when a user takes action. The first step is breaking up long tasks. Any JavaScript task that runs for more than 50 milliseconds is considered a long task by browser profiling tools.

Modern browsers provide native scheduling methods like yield mechanisms that allow long tasks to pause, let the browser paint the requested visual update, and then continue working on lower-priority background logic. In React and Next.js, using features like transitions helps separate urgent interface updates from secondary data calculations.

Cleaning up your script payload is equally critical. Delay loading non-critical analytics and customer support widgets until the visitor actually scrolls down or indicates intent to interact. If you are planning a modern build or a WordPress to Next.js migration, auditing your external scripts early ensures you only ship the JavaScript you genuinely need.

Practical takeaways for your team

A fast initial load time means very little if your visitors cannot comfortably tap a menu, open a filter, or submit a form without waiting. INP holds your website accountable for how it behaves during real-world usage, not just on initial page load.

Check your Core Web Vitals report in Google Search Console to see if your live pages pass the 200-millisecond threshold across mobile and desktop devices. If you see high interaction latency, review your third-party script burden and inspect your JavaScript event handlers before investing time in visual redesigns.

Want help with this? See my Speed & Core Web Vitals fix service, or send me your site for a free review.