If your site felt fast three years ago but is failing performance reports today, you are not alone. First Input Delay is dead. Google replaced it with Interaction to Next Paint back in 2024, and the shift exposed thousands of websites that were masking terrible interaction delays behind fast initial load times.
This post covers why the metric changed and everything you need to know about INP optimization in 2026.
When you check your Google Search Console today, INP issues usually show up in the mobile report first. Mobile devices have weaker processors than desktops. When heavy JavaScript runs, those mobile processors choke. The user taps a button, nothing happens for a full second, and then the site suddenly reacts. That is a poor user experience, and Google now penalizes it heavily in search rankings.
What This Post Covers
- Why First Input Delay was a flawed metric and how sites gamed it
- How INP works: the three phases of every interaction
- Concrete optimization strategies for each INP phase
- How to measure INP with field and lab data
- Real-world fixes for the most common INP killers
Why First Input Delay Was Flawed
First Input Delay only measured the very first interaction a user had with your page. It also only measured the input delay itself — the time between a user clicking a link and the browser beginning to process that click.
It did not measure the time it took to actually process the event. It did not measure the time it took to paint the visual update to the screen. If a user clicked a menu icon and the browser took three seconds to animate the menu opening, FID might still report a perfect score.
How Sites Gamed FID
Developers quickly figured out how to exploit FID. They prioritized the initial paint and deferred heavy scripts until right after load. The site looked ready to use, but when users actually tried to interact, the main thread was frozen. FID rewarded the illusion of speed rather than actual responsiveness. A page could score a perfect FID while being completely unresponsive to every interaction after the first one.
Enter Interaction to Next Paint
Interaction to Next Paint is far more ruthless. It measures the latency of all click, tap, and keyboard interactions throughout the entire lifespan of a user's visit.
INP calculates the total time from the moment the user initiates the interaction until the browser presents the next visual frame to the screen. If a user clicks five different tabs on a product page, INP evaluates the latency of all those clicks and typically reports the worst one.
This creates a comprehensive picture of page responsiveness. You cannot trick INP by simply delaying scripts. If a heavy script freezes the page two minutes into a user session and they try to click a button during that freeze, your INP score tanks.
FID vs. INP at a Glance
| First Input Delay (FID) | Interaction to Next Paint (INP) | |
|---|---|---|
| Interactions measured | First interaction only | All interactions during the full session |
| What it measures | Input delay only (time until event handler starts) | Full round-trip: input delay + processing + presentation |
| Reported value | The single first interaction | Worst interaction (approximated at 98th percentile) |
| Good threshold | ≤ 100ms | ≤ 200ms |
| Gameable? | Yes — defer scripts past first interaction | No — every interaction counts |
| Status | Deprecated (March 2024) | Active Core Web Vital |
The Three Phases of Every INP Interaction
To succeed at INP optimization, you need to break the metric into its three distinct phases. Every single interaction consists of an input delay, a processing time, and a presentation delay. Each phase has different root causes and different fixes.
Anatomy of an INP Interaction
INP = Phase 1 + Phase 2 + Phase 3. The total must be ≤ 200ms for a "Good" score. Any phase can be the bottleneck.
Phase 1: Input Delay
This is the time a user waits for the browser to even acknowledge the interaction. The most common cause of high input delay is background tasks blocking the main thread. If the browser is busy executing a massive JavaScript bundle when the user taps a button, the tap has to wait in line.
Common Input Delay Causes
- Third-party analytics or ad scripts executing heavy code on the main thread
- Large JavaScript bundles parsing and compiling during idle moments — a user click that lands during compilation is delayed
setIntervalorrequestAnimationFramecallbacks that run continuously and consume thread time- Synchronous
localStorageorIndexedDBreads triggered by background logic
Phase 2: Processing Time
Processing time is how long your code takes to run in response to the interaction. Complex event listeners, inefficient DOM manipulation, and unoptimized React state updates often bloat this phase. If your event handler parses a massive JSON object or triggers a full component tree re-render before doing anything visible, processing time spikes.
Phase 3: Presentation Delay
The browser has processed the event and now needs to calculate layout changes and paint the new pixels to the screen. Highly complex CSS selectors and massive DOM trees cause severe presentation delays. The more elements the browser has to recalculate, the longer it takes to paint the next frame.
Essential Strategies for INP Optimization
Improving your INP score requires a combination of JavaScript reduction, main thread management, and DOM optimization. Here are the most impactful fixes, ordered by typical return on effort.
1. Yield to the Main Thread
The single most effective INP optimization technique is breaking up long tasks. A long task is any piece of JavaScript execution that takes longer than 50 milliseconds.
When you have a long task, the browser cannot respond to user input until it finishes. You need to identify these tasks in Chrome DevTools and break them into smaller chunks.
Before: Monolithic handler (blocks main thread)
button.addEventListener('click', () => {
processLargeDataset(); // 150ms
updateDOM(); // 80ms
sendAnalytics(); // 40ms
});
// Total: 270ms locked on main thread
After: Yielding between chunks
button.addEventListener('click', async () => {
updateDOM(); // visual feedback first
await scheduler.yield(); // let browser paint
processLargeDataset(); // heavy work after paint
await scheduler.yield();
sendAnalytics(); // non-critical last
});
// INP sees only the time to first paint
The scheduler.yield() API is the modern way to yield. For browsers that do not yet support it, await new Promise(r => setTimeout(r, 0)) achieves a similar effect. Think of it like a polite conversation instead of a monologue — the script talks for a moment, pauses to see if the user needs anything, and then continues.
2. Minimize DOM Complexity
A massive DOM tree destroys rendering performance. When a user interacts with a page and triggers a visual change, the browser recalculates how that change affects surrounding elements.
If your page has 5,000 DOM nodes, those calculations take significantly longer than if you have 500 nodes. E-commerce sites are notorious for this. Mega menus, infinite scroll product grids, and hidden modal windows bloat the DOM.
DOM Size Targets
| Metric | Good | Concerning | Critical |
|---|---|---|---|
| Total DOM nodes | < 800 | 800 – 1,400 | > 1,400 |
| Max DOM depth | < 32 | 32 – 60 | > 60 |
| Max child elements | < 60 | 60 – 120 | > 120 |
Audit your page structure. Remove hidden elements that are not immediately necessary. Use virtual scrolling for long lists so only the visible elements are rendered. Simplifying your HTML structure naturally improves both INP and rendering performance because there is simply less for the browser to process.
3. Optimize Third-Party Scripts
Third-party scripts are often the silent killers of INP scores. Chat widgets, analytics trackers, and advertising scripts frequently execute heavy code on the main thread without your direct control.
You cannot edit the code of a third-party tool. You can, however, control when and how it loads:
Third-Party Script Loading Strategies
| Strategy | How It Works | Best For |
|---|---|---|
| Defer until idle | Load script via requestIdleCallback or after user's first interaction |
Analytics, heatmaps, non-critical tracking |
| Web Worker (Partytown) | Move script execution to a background thread entirely | Heavy analytics (GA4), ad scripts, tag managers |
| Facade pattern | Show a static placeholder; load the real widget only on user interaction | Chat widgets, embedded video players, social embeds |
| Remove entirely | Evaluate ROI vs. SEO penalty; remove if net negative | Unused tracking pixels, redundant tools, abandoned A/B tests |
4. Streamline Event Listeners
Bloated event listeners directly increase processing time. When a user clicks a button, every function attached to that click event must execute.
Audit your event listeners. Ensure you are not running redundant calculations. Debounce or throttle events that fire rapidly, like scroll and resize events. If an interaction requires heavy computation, provide visual feedback immediately before the heavy lifting begins.
The Instant Feedback Trick
Users need instant visual confirmation that their click registered. A simple CSS state change — a button color change, a loading spinner, a pressed animation — takes almost zero processing time and keeps perceived latency incredibly low. Apply the visual change before any heavy JavaScript runs. The browser paints the feedback to screen, and then your code can take as long as it needs to finish the actual work. INP measures time to next paint, not time to task completion.
5. Reduce CSS Complexity for Faster Presentation
Presentation delay is the most overlooked INP phase. After your JavaScript finishes, the browser still needs to recalculate styles, compute layout, and paint pixels.
Presentation Delay Fixes
- Avoid layout thrashing — do not read layout properties (like
offsetHeight) and then write styles in the same synchronous block. Batch reads and writes separately. - Use
content-visibility: auto— tells the browser to skip rendering off-screen elements until they scroll into view, reducing recalculation work. - Prefer
transformandopacityanimations — these run on the compositor thread and do not trigger layout recalculation. Animatingwidth,height,top, orleftforces expensive layout work. - Simplify CSS selectors — deeply nested selectors like
.sidebar > .widget:nth-child(3) .link spanare slower to match than flat class selectors. On large DOM trees, selector matching overhead becomes measurable.
Measuring Your INP Performance
You cannot optimize what you do not measure. Relying solely on Google Search Console is a mistake because the data is aggregated over 28 days. By the time you see an INP drop in GSC, you have been providing a poor experience for weeks.
INP Measurement Tools
Field Data (Real Users)
- CrUX Dashboard — weekly trends of 75th percentile INP for your origin
- Search Console — identifies which URL groups fail the 200ms threshold
- web-vitals.js — measure INP in production and send to your analytics
Lab Data (Debugging)
- Chrome DevTools Performance tab — record traces, find long tasks, inspect event handlers
- Web Vitals Extension — real-time INP overlay as you click through your site
- Lighthouse Timespan mode — measure INP during a specific interaction sequence
Pro Tip: Use Lighthouse Timespan Mode
Standard Lighthouse audits only measure page load. Timespan mode lets you start recording, interact with the page (click buttons, open menus, fill forms), and then stop. Lighthouse will report INP for those specific interactions, letting you pinpoint exactly which UI elements have the worst latency. Open DevTools → Lighthouse → select "Timespan" instead of "Navigation."
The Bottom Line on INP
Interaction to Next Paint is the most technically demanding Core Web Vital to optimize. It forces developers to write efficient code and prioritize the user experience throughout the entire session, not just during the initial load.
Fast loading is no longer enough. Your site must be immediately and consistently responsive. If your competitors have smooth, instant interactions while your site stutters on mobile devices, Google will rank them higher.
The optimization priority is clear: yield to the main thread, minimize DOM complexity, control third-party scripts, and provide instant visual feedback. Run your site speed audit today with a focus on the Performance panel's interaction traces, and you will find exactly where those 200+ millisecond interactions are hiding.
Struggling to find what is blocking your main thread?
Barracuda SEO runs comprehensive technical audits that pinpoint exactly which scripts and interactions are tanking your INP — with prioritized fixes your developers can execute immediately.
Try Barracuda SEO Free