What INP is and how to fix a slow one
Interaction to Next Paint measures how quickly your page responds when a visitor taps, clicks, or presses a key. It became a Core Web Vital in March 2024, replacing First Input Delay, because it captures the whole interaction and not just the first one. Google's web.dev documentation sets the target plainly: “To provide a good user experience, sites should strive to have an INP of 200 milliseconds or less.” Almost every slow INP traces to the same cause: too much JavaScript running on the main thread when the user acts.
The symptom: the page looks ready but does not react
A visitor taps a button, opens a menu, or types in a field, and nothing happens for a beat. The page loaded, it looks finished, but it feels frozen for a fraction of a second on every interaction. That lag is INP. Unlike a slow load, which people forgive once, a laggy interaction repeats every single time they touch the page, and it reads as "cheap" or "broken" even when everything technically works.
The number that counts is the field number: your INP at the 75th percentile of real Chrome users. Above 200 milliseconds is documented as needing improvement; above 500 is poor. A phone in someone's hand is where this shows up worst, because phones have less processing power than the laptop you built the site on.
The cause: the main thread is busy when the user acts
A browser has one main thread that handles both your JavaScript and the visible response to a tap. If a long script is running when the user acts, the response has to wait in line behind it. The usual culprits:
- Long JavaScript tasks. A single script that runs for hundreds of milliseconds blocks every interaction that lands during it.
- Heavy third-party tags. Analytics, chat widgets, ad scripts, and tag managers all compete for the same thread, and you did not write any of them.
- An oversized DOM. A page with thousands of elements is more expensive for the browser to update after every interaction.
- Work done on every keystroke or scroll. Event handlers that do heavy work on each event pile up fast.
The fix: give the main thread room to respond
The goal is simple: when the user acts, the thread should be free to paint the response quickly.
- Break long tasks into smaller pieces and yield to the main thread between them, so an interaction can slip in.
- Defer or lazy-load JavaScript the first view does not need, and drop third-party tags no one can justify.
- Trim an oversized DOM, and avoid rendering thousands of rows the visitor cannot see at once.
- Debounce heavy work on high-frequency events like scroll, input, and resize.
// Yield so a pending tap can be handled between chunks async function processInChunks(items) { for (const chunk of splitIntoChunks(items)) { doWork(chunk); await new Promise(r => setTimeout(r, 0)); // let the browser respond } } // Defer scripts that do not shape the first interaction <script src="/analytics.js" defer></script>
Google's optimize INP guide walks these steps with the profiling traces to find which task is yours. The theme repeats across the vitals: less JavaScript in the critical path helps INP, and it also helps Largest Contentful Paint.
Be honest: this is the hardest vital to fake
Two cautions. First, a clean Lighthouse run does not prove a good INP, because lab tools cannot fully simulate a real person tapping around on a mid-range phone. INP is judged on field data or not at all. Second, INP is often a symptom of a bloated stack rather than one bad line of code. If your page ships a large framework bundle to render text that could have been plain HTML, the honest fix is shipping less JavaScript, not adding a clever workaround on top of it.
Verify: read the field number, then re-test on a phone
Run your URL through PageSpeed Insights and read the field section first, where INP sits beside LCP and CLS. If you are new to that report, we walk it in plain language in how to read PageSpeed Insights. Then check the hub: run a Core Web Vitals audit on your site to see all three together. Field data is a rolling 28-day window, so improvements surface over weeks.
Then read the page the way a crawler does. Paste your link into our GEO audit or the full AuditLamp audit and we flag the third-party script count and DOM size that most often sit behind a slow INP. The rest of the fix library covers the failures speed alone cannot solve.