# INP: how to fix a website that is slow to respond to clicks > What INP (Interaction to Next Paint) is, how to measure it, why your site responds slowly to clicks and the most effective fixes in JavaScript, third parties and rendering. URL: https://codegea.com/en/inp-how-to-fix-a-website-that-is-slow-to-respond-to-clicks Web · 2026-10-05 · Derian Pinto 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](/en/core-web-vitals-in-2026-what-they-are-and-how-to-improve-them) 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](/en/astro-vs-nextjs-for-landing-pages-performance-and-seo-compared). ### 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](/en/server-caching-redis-varnish-and-opcache-what-each-one-does). ## 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](/en/checkout-mistakes-that-cost-you-sales-in-ecuador) and your site's [performance optimization](/en/supercharge-your-website-key-tips-for-web-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](/en/retainer). Learn about our [corporate websites](/en/services/corporate-website-development) service or request a review from [contact](/en/contact).