Optimize INP: A Practical Guide to Killing Interaction Latency (Long Tasks, JS)
Since March 2024, INP (Interaction to Next Paint) has officially replaced FID (First Input Delay) in Google’s Core Web Vitals. Plenty of sites that showed an excellent FID score are discovering, now that INP is the metric that counts, that their page becomes genuinely unpleasant to use the moment a visitor clicks a menu, opens a filter, or fills out a form. This guide explains why, and more importantly, how to diagnose the exact cause in your own code.
What INP Actually Measures
Unlike FID, which only looked at the delay before the browser started processing an event, INP covers the full interaction cycle across three distinct phases:
- Input Delay — the time between the visitor’s physical action (click, tap, keypress) and the moment the browser actually starts executing the corresponding event handler. This delay spikes when the main thread is already busy with something else.
- Processing Time — how long your JavaScript code takes to run in response to that interaction (state updates, API calls, DOM manipulation).
- Presentation Delay — the time between the end of processing and the moment the browser actually paints the visual result on screen.
Google records the worst interaction (or close to the worst, statistically) observed across the visitor’s entire session - not just the first one. That’s what makes INP far more representative of real experience than a single startup-time number.
| Band | INP Threshold |
|---|---|
| Good | Under 200ms |
| Needs Improvement | 200ms to 500ms |
| Poor | Over 500ms |
Root Cause #1: Long Tasks
A “Long Task” is a JavaScript task that occupies the browser’s main thread for more than 50 milliseconds without yielding. While a Long Task is running, the browser can’t process any user interaction - the click is still registered by the operating system, but your page literally cannot respond to it until the current task hands control back.
The most common causes of Long Tasks:
- Large JavaScript bundles executed in a single block at load time, often entire front-end frameworks hydrating in one pass.
- Uncontrolled third-party scripts — chat widgets, tracking pixels, exit-intent pop-ups — that run whenever they want, on the main thread, without you having any say in it.
- Cascading style recalculations and reflows, typically caused by DOM manipulation inside loops that force the browser to recompute layout on every iteration.
- Client-side data processing — sorting, filtering, or transforming large lists in plain JavaScript instead of delegating it to the server or chunking the work.
How to Diagnose Long Tasks in Your Own Code
Diagnosis happens in two stages: first confirming a responsiveness problem exists, then pinpointing the exact line of code responsible.
Step 1 — Confirm the problem with real data. A Core Web Vitals audit based on field data (via the Chrome UX Report) shows the actual INP measured from real visitors, not a lab estimate. Our free audit tool surfaces this data directly, with the exact Google threshold, instead of an opaque score.
Step 2 — Locate the Long Task with DevTools. Open Chrome DevTools’ Performance tab, record a session while clicking through the page’s interactive elements (menu, filter, add-to-cart button), then look for the blocks flagged in red in the timeline - those are your Long Tasks. Chrome shows the exact JavaScript call stack responsible, which takes you straight to the offending file and line, no guessing involved.
Step 3 — Break the work into chunks. Once the offending function is identified, the most reliable fix is to split the processing into smaller chunks using scheduler.yield() (or, as a fallback, setTimeout(fn, 0)) to regularly hand control back to the main thread between chunks, instead of running the whole calculation as one uninterrupted block.
Reducing Input Delay: Taking Back the Main Thread
Even fast processing code doesn’t help if Input Delay is already high because the main thread was busy elsewhere at the moment of the click. The concrete levers:
- Split JavaScript bundles with route-based code-splitting, so only the code actually needed for the displayed page gets loaded and executed.
- Defer non-critical third-party scripts with
deferor lazy-loading triggered after the initial interaction, instead of at page load. - Limit initial-load work to elements that are actually visible and immediately interactive - everything else can hydrate afterward.
- Avoid heavy event handlers attached directly to high-interaction elements (long lists, tables), preferring event delegation instead.
Reducing Processing Time: Optimizing the Code That Responds to the Click
Once the main thread is back under control, the second target is the code that actually runs in response to the interaction:
- Debounce or throttle handlers triggered at high frequency (search-box typing, scroll, resize) to avoid re-running heavy processing on every keystroke.
- Memoize expensive calculations that don’t change between renders, instead of recomputing them on every interaction.
- Reduce redundant DOM manipulation — batching DOM reads and writes separately avoids triggering multiple unnecessary reflow cycles for a single interaction.
Diagnose Your Own INP
INP is inherently a field metric - it can only be measured from real visitor interactions, unlike LCP or CLS which can be reliably simulated in a lab. That’s precisely why many audit tools ignore it or approximate it poorly.
Run a free Core Web Vitals audit of your site →
Our tool surfaces the Core Web Vitals metrics that are actually available, with the exact Google thresholds, giving you a concrete starting point instead of an anxiety-inducing score.
Need a Deeper Diagnosis?
Pinpointing the exact line of code responsible for a recurring Long Task on a production site usually requires targeted, page-by-page profiling. That’s the kind of work we do as part of our technical SEO services, with real before-and-after measurements instead of a generic recommendation.
Published by the Runkexpert Engineering Team. Last updated July 15, 2026.