INP: how to fix a website that is slow to respond to clicks

You click a menu, "add to cart" or a filter and the page takes a while to react. That feeling has a name and a number: INP (Interaction to Next Paint), the metric Google uses to measure how fast a page responds when someone interacts with it. It is one of the three Core Web Vitals and, in practice, the hardest to fix.

INP measures the time between a user's action and the moment the screen shows a response. If it is slow, the user feels your site "does not respond".

What it measures exactly

Every time someone clicks, taps the screen or presses a key, the browser:

1. Receives the action (sometimes it has to wait if it is busy).
2. Runs the associated code (the event "handlers").
3. Updates the screen with the result.

INP takes the interactions of a visit and reports, roughly, the slowest one (with exceptions for visits with many interactions). Google considers an INP of 200 ms or less good, and one above 500 ms poor.

How to measure it

• Real data (field): Search Console (Core Web Vitals report) and PageSpeed Insights show the INP of your real visitors.
• Local testing: Chrome's developer tools let you record interactions and see which are slow and why.
• Your own measurement: you can capture it in your analytics with Google's web-vitals library.

Measure on a real or simulated mid-range phone, not just your powerful computer: that is where the problem shows.

Why a site responds slowly

It is almost always one of these causes:

1. The main thread is busy

The browser processes JavaScript, styles and painting on a single thread. If it is running a long task, the click waits. Tasks longer than 50 ms already start to be noticeable.

2. Too much JavaScript

Every library, widget and script adds download, parse and execution time. Sites that load heavy frameworks to show almost static content pay for it on every interaction.

3. Third-party scripts

Chat, analytics, advertising pixels, maps, heatmaps: each one competes for the main thread. They are usually the most underestimated cause.

4. Slow event handlers

A click that triggers heavy calculations, updates many elements or waits for a server before showing something.

5. Costly rendering

Pages with a huge DOM, styles that force the whole layout to be recalculated, long lists that are not virtualized or animations that force constant work.

How to fix it, in order of impact

Reduce and split JavaScript

• Remove libraries you no longer use.
• Load only what is needed on each page (code splitting).
• Defer what is not needed at the start (load on interaction or when visible).
• For content sites, consider an architecture that sends little JavaScript to the browser. Compare approaches in Astro vs Next.js for landing pages.

Control third-party scripts

• Take inventory and remove the ones that add nothing.
• Lazy-load those that are not critical.
• Consider replacing a heavy widget with a lightweight alternative or a link.

Break up long tasks

If an action needs a lot of work, split the process into chunks and hand control back to the browser between them, so it can paint and respond. The first thing the user expects to see (for example, a button changing state) should show right away, and the rest can happen afterwards.

Respond first, compute later

On a click, update the interface immediately (loading state, button pressed) and do the heavy work or the server request without blocking. This is called an optimistic response and improves perception even if the operation takes the same time.

Simplify rendering

• Keep the DOM small: fewer elements, less nesting.
• Avoid costly layout changes during interaction.
• Virtualize long lists.
• Review animations: use cheap properties (such as transform and opacity).

Look after the server and the cache

If the interaction depends on a server response, the backend counts too. Caching, efficient queries and a good server cut the wait. See server caching.

In stores and sites with filters

Catalog filters, the cart and checkout are where a high INP hurts most, because they are close to the purchase. Review the checkout mistakes that cost sales and your site's performance optimization.

A practical order of work

1. Measure your real INP and detect which pages and interactions are the worst.
2. Reproduce the problem in the developer tools.
3. Fix the main cause (almost always, too many scripts or too much JavaScript).
4. Measure again and confirm the improvement with real data; field data takes a few weeks to update.
5. Watch that it does not get worse again with each new plugin or script.

How we do it at Codegea

We audit your site's performance, identify which interactions are slow and fix the cause in the code, the third-party scripts and the server. To keep the results over time, we fold it into a retainer plan. Learn about our corporate websites service or request a review from contact.