Core Web Vitals in 2026: A Practical INP Optimization Guide

INP optimization is the work of making every click, tap and key press on your site produce visible feedback fast. Interaction to Next Paint (INP) is the Core Web Vital that measures this responsiveness, and in 2026 it is the metric most sites still fail. This guide explains how INP works, how to find the interactions dragging your score down, and the fixes that actually move it.

What is INP and why does it matter in 2026?

INP is a Core Web Vital that measures how long a page takes to paint the next frame after a user interacts with it, observed across the whole visit. It replaced First Input Delay (FID) as a Core Web Vital on March 12, 2024, because FID only measured the delay before the first interaction's handlers started.

According to web.dev's INP documentation, the thresholds are assessed at the 75th percentile of field page loads, split by mobile and desktop:

• Good: 200 milliseconds or less.
• Needs improvement: more than 200 ms and up to 500 ms.
• Poor: more than 500 ms.

INP counts mouse clicks, touchscreen taps and key presses on physical or onscreen keyboards. Hovering, scrolling and zooming are not counted. The reported value is the longest interaction observed, with one outlier ignored for every 50 interactions on busy pages.

Users forgive a slow first load far more readily than a button that seems to ignore them.

What are the three parts of a slow interaction?

Every interaction's latency is the sum of three phases: input delay, processing duration and presentation delay. Diagnosing which phase dominates tells you which fix to apply.

How do you find the interactions that hurt your INP?

Start with field data from real users, because lab tools cannot guess which interactions your visitors actually perform. Then reproduce the worst ones in the lab to debug them.

1. Check PageSpeed Insights, which reports Chrome User Experience Report (CrUX) data, to see whether your URLs or origin pass INP on mobile and desktop.
2. Review the Core Web Vitals report in Google Search Console to see which groups of pages share the problem.
3. Add real user monitoring (RUM). The open-source web-vitals library's attribution build reports the target element, the interaction type and the time spent in each phase.
4. Use the Long Animation Frames API (LoAF), shipped in Chrome 123, to see which scripts ran during a slow frame. The web-vitals library (v4 and later) attaches overlapping LoAF entries to its INP attribution.
5. Reproduce the slowest interaction in the Chrome DevTools Performance panel with CPU throttling, and look for long tasks and forced layouts flagged with a red triangle.

LoAF is especially useful for third-party problems. Each entry lists scripts that ran longer than 5 ms, with their source URL and how they were invoked, so you can prove which tag is blocking the main thread.

How do you reduce input delay?

Reduce input delay by keeping the main thread free when users are most likely to interact, which is usually during and just after page load. Input delay is rarely caused by the handler itself; it is caused by whatever else is running.

• Audit third-party scripts such as chat widgets, A/B testing tools and tag managers, and remove or delay the ones that do not earn their cost.
• Code-split JavaScript so each route loads only what it needs, and defer non-critical bundles.
• On React and similar frameworks, reduce hydration cost with server components, partial or progressive hydration, or islands, as covered in our guide to JavaScript SEO with SSR and SSG.
• Avoid timers and polling loops that fire long tasks every few seconds.
• Move heavy computation such as parsing large JSON or filtering big lists to a Web Worker.

How do you speed up long event handlers?

Speed up event handlers by doing only the work needed for the next visual update, then yielding to the main thread so the browser can paint before the rest runs. Yielding splits one long task into several shorter ones.

The modern way to yield is `scheduler.yield()`. According to Chrome's developer guidance, the code after the await is queued ahead of other similar tasks, unlike `setTimeout`, which places it at the back of the queue. Chrome and Edge 129 and Firefox 142 support it; Safari does not, so feature-detect and fall back.

1. Update the UI first: show the pressed state, spinner or optimistic result.
2. Call `await scheduler.yield()` when available, otherwise `await new Promise(r => setTimeout(r, 0))`.
3. Run the remaining work, such as data fetching, analytics events and secondary renders, after the yield.
4. Repeat the yield inside long loops so no single chunk runs for more than a few dozen milliseconds.

How do you cut presentation delay?

Cut presentation delay by reducing the rendering work the browser must do after your handlers finish. The web.dev guide to optimizing INP highlights DOM size, layout thrashing and client-side rendering as the main culprits.

• Keep the DOM small and shallow; virtualize long lists and tables instead of rendering thousands of rows.
• Apply the CSS `content-visibility` property to off-screen sections so the browser skips rendering them until needed.
• Avoid layout thrashing: batch style reads before writes instead of reading layout values right after changing them.
• Avoid rendering large chunks of HTML with JavaScript in a single update; render progressively or on the server.
• Prefer CSS transitions on transform and opacity over animations that trigger layout.

Which INP fixes fit your stack?

The right fix depends on where the main thread time goes, and that pattern differs by platform. Use this as a starting checklist, not a substitute for field data.

How Advotis Agency can help

INP improvements stick when they are measured, prioritized and protected in your release process. Our web experience team sets up RUM, traces your slowest interactions and ships targeted fixes, and our analytics and CRO specialists connect responsiveness to conversion. Contact our team for an INP audit of your key templates.

Frequently asked questions

Advotis Engineering Team

Written and reviewed by the Engineering Team at Advotis Agency — specialists who build and grow websites, apps and AI products for clients every day. About us