Optimising INP in 2026: What to Fix First (and What Usually Doesn't Matter)
INP optimisation advice is everywhere, but not all fixes deliver equal results. Some changes dramatically improve responsiveness; others consume development time with negligible impact. This guide ranks optimisation strategies by actual effectiveness so you fix what moves the needle first.
The fixes that deliver the biggest impact
Removing or deferring heavy third-party scripts consistently produces the largest INP improvements. Analytics suites, ad networks, chat widgets, and social media embeds collectively consume significant main thread time. Audit them ruthlessly. Defer everything that doesn’t need to run before the page becomes interactive.
Breaking up long JavaScript tasks is the second-highest-impact change. Any task over 50ms blocks user interactions. Using yield patterns—setTimeout(0), scheduler.yield(), or requestAnimationFrame—between logical units of work keeps the main thread available for input processing. This single technique often cuts INP by 30-50%.
Reducing JavaScript bundle size decreases parse and compile time, which directly reduces long tasks during page load and navigation. Code splitting, tree shaking, and lazy loading non-critical modules prevent the browser from processing JavaScript the user hasn’t needed yet. Less code means less main thread competition.
The fixes that matter moderately
Optimising event handlers—the functions that respond to clicks, keypresses, and other interactions—matters when those handlers contain expensive logic. Database-like filtering of large arrays, complex state calculations, or DOM queries across thousands of elements inside handlers directly increase processing time.
Moving work off the main thread using web workers helps for computationally expensive operations. Data processing, complex calculations, and formatting tasks can execute in workers without blocking interactions. The overhead of worker communication means this only helps for operations taking more than a few milliseconds.
Reducing DOM size improves style recalculation and layout performance after handlers modify the page. Pages with over 1,500 DOM elements start showing measurable rendering overhead. Simplifying page structure or virtualising long lists of elements keeps rendering fast.
The fixes that rarely move the needle
Micro-optimising JavaScript execution—replacing forEach with for loops, avoiding arrow functions, or hand-optimising algorithms—almost never improves INP measurably. Modern JavaScript engines optimise these patterns well. The overhead difference is microseconds, not the milliseconds that affect INP.
Adding will-change CSS hints aggressively doesn’t help INP. This property helps animation performance by promoting elements to compositor layers, but it doesn’t speed up event handler execution or reduce main thread blocking. Overusing it wastes GPU memory without INP benefit.
Switching frameworks purely for INP performance is rarely justified. React, Vue, Svelte, and vanilla JavaScript can all achieve good INP. The framework matters less than how you use it—specifically, how much work happens synchronously during interactions. Framework migration is expensive; fixing interaction patterns within your current framework is almost always more effective.
Priority order for most sites
Start with a third-party script audit. List every external script, measure its main thread impact, and remove or defer scripts with high cost and low value. This requires no code changes to your application—just changing when and whether scripts load.
Next, identify and break up your longest tasks. Record a Performance profile in DevTools and sort by task duration. The top 5-10 longest tasks are your targets. Breaking each into smaller chunks progressively improves INP.
Then audit your most-interacted-with components. If users click a filter dropdown hundreds of times per session, that dropdown’s handler performance matters enormously. Optimise the hot paths—the interactions that happen most frequently and affect INP assessment.
Finally, monitor field INP data to confirm improvements. Lab testing guides fixes, but field data from real users across real devices confirms whether changes actually helped. The gap between lab and field can be significant.
How to measure whether a fix actually helped
Before any change, record baseline INP measurements—both lab (DevTools) and field (CrUX/Search Console). After deploying the fix, compare. An INP improvement that doesn’t show in field data within 28 days may not be benefiting real users.
Use the Web Vitals attribution build to identify which interaction element and type contributes to INP. This granularity reveals whether your fix addressed the right interaction. Improving a menu toggle’s responsiveness doesn’t help if the search filter is the actual INP bottleneck.
Track INP regression alongside code changes. When a new feature or library introduces main thread work, INP can regress. Automated performance budgets in CI/CD pipelines catch these regressions before they reach production.
Practical principles
Focus on the main thread. INP is fundamentally a main thread availability problem. Any fix that reduces main thread occupation improves INP. Any change that doesn’t affect the main thread won’t help.
Prioritise high-frequency interactions. INP reports near-worst-case across all interactions. But the interactions users perform most frequently are most likely to produce that worst case. Optimise what users actually do, not theoretical edge cases.
Accept diminishing returns. Moving INP from 500ms to 200ms is achievable with focused effort. Moving from 200ms to 50ms requires disproportionate effort for marginal benefit. Get below the 200ms threshold, then maintain it rather than chasing perfection.
The most effective INP work combines measurement, targeted fixes, and ongoing monitoring. If you’re unsure which fixes matter most for your specific site, a focused performance review can identify the highest-impact changes and estimate their likely effect before you invest development time.