How to improve Interaction to Next Paint (INP)

To learn how to improve Interaction to Next Paint, start with one fact: INP measures how long your page takes to visibly respond after someone taps, clicks or types, and a good score is 200 milliseconds or less (opens in new tab). You improve it by finding your slowest interactions in field data, seeing which part of the interaction takes the time, and then shortening it: break up long JavaScript tasks, load less script, and keep screen updates small.

What does INP measure, and what is a good score?

INP measures the time from a user's interaction to the next frame the browser paints, and Google rates it good at 200 milliseconds or less. According to web.dev's INP guide (opens in new tab), scores between 200 and 500 milliseconds need improvement and anything above 500 milliseconds is poor. Like the other Core Web Vitals, it's judged at the 75th percentile of page visits, so most of your visitors need a fast response, not just the ones on fast devices.

INP looks at every click, tap and key press during a visit and reports one of the slowest. That makes it stricter than the metric it replaced. Interaction to Next Paint became a Core Web Vital in March 2024 (opens in new tab), replacing First Input Delay, which only measured the wait before the first interaction started being handled.

Google lists INP alongside Largest Contentful Paint and Cumulative Layout Shift in its Core Web Vitals documentation (opens in new tab). If you're new to all three, read Core Web Vitals explained first.

How do you find your slow interactions?

Find slow interactions by starting with field data, which tells you which pages fail, and then using Chrome DevTools to see which interactions on those pages are slow.

• Search Console's Core Web Vitals report. It groups URLs with similar problems and flags "INP issue" groups for mobile and desktop separately. Start with the group that covers the most pages.
• PageSpeed Insights. Enter a failing URL and look at the field data section at the top. It shows that page's real-user INP, if Chrome has enough data for it.
• Chrome DevTools. Open the Performance panel, start recording, and use the page the way a visitor would: open the menu, submit the form, filter the product list. The interactions track shows each interaction's duration, and long ones are marked.

A common pattern: the page loads fine, but one specific action, such as opening a mobile menu or typing in a search box, is slow. Field data tells you a problem exists; the trace tells you exactly where.

Lab tests can't fully reproduce INP, because it depends on what real people click. If you can't reproduce a slow interaction, test on a slower device, or turn on CPU throttling in DevTools to mimic a mid-range phone.

Our website speed test guide walks through these tools in more detail.

How to improve Interaction to Next Paint, part by part

Every interaction has three parts (input delay, processing time and presentation delay), and you improve INP by shortening whichever one is long. web.dev's guide to optimizing INP (opens in new tab) breaks it down this way:

1. Input delay is the wait before your event handlers start running. It's long when the main thread is busy with something else, such as a script still loading or a timer firing.
2. Processing time is how long your event handlers take to run. It's long when the code that responds to a click does too much work at once.
3. Presentation delay is the time from the handlers finishing to the browser painting the next frame. It's long when the update causes a lot of layout and rendering work.

In a DevTools trace, click on a slow interaction and you'll see this split. If input delay dominates, look at what else was running. If processing dominates, look at your handler. If presentation dominates, look at how much of the page you changed.

Fix 1: break up long tasks and yield to the main thread

The most effective INP fix is to break long JavaScript tasks into smaller pieces so the browser can respond to input between them. The browser can only do one thing at a time on the main thread. Any task that runs for a long time blocks every click and tap until it's done.

web.dev's guidance on long tasks (opens in new tab) recommends yielding: doing the urgent part of the work, then giving control back to the browser before doing the rest. In practice that means:

• Do the visible update first (show the menu, mark the button as pressed), then run analytics, saving and other background work after a yield.
• Split big loops, such as filtering a long list, into chunks.
• Move work that doesn't touch the page into a web worker where possible.

A short example of yielding:

button.addEventListener('click', async () => {
  showResult();               // the part the user sees
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0));
  sendAnalytics();            // the part that can wait
});

The idea is the same whatever framework you use: let the browser paint the response before doing the extra work.

Fix 2: cut and defer JavaScript, including third-party tags

Less JavaScript means a less busy main thread, which means shorter input delays. Every script you load has to be downloaded, parsed and run, and much of that work happens right when visitors start to interact.

• Remove what you don't use. Old tracking pixels, abandoned A/B testing tools and plugins nobody remembers installing are common.
• Defer what can wait. Chat widgets, review carousels and social embeds rarely need to load before a visitor scrolls or clicks. Load them on interaction or after the page is idle.
• Watch your tag manager. A single container can quietly load dozens of tags. Audit it, and give each tag a reason to exist.
• Split your own code. Load the code for each page and feature when it's needed, not the whole site's code on every page.

In a performance trace, group activity by domain to see how much time third-party scripts take. It's often more than the site's own code.

Fix 3: keep DOM and rendering updates small

Long presentation delays come from asking the browser to redraw too much after an interaction. The fix is to change less, and change it more cheaply.

• Keep the DOM lean. Pages with a very large number of elements take longer to lay out and paint. Paginate or virtualize long lists rather than rendering everything at once.
• Update only what changed. Re-rendering a whole page section to change one label adds work for no benefit.
• Avoid forced layouts. Reading layout values (like an element's height) right after changing styles forces the browser to calculate layout early. Batch your reads and writes.
• Use CSS containment on self-contained widgets, so a change inside them doesn't make the browser recheck the whole page.

Give instant feedback on slow actions

When an action genuinely takes time, such as submitting a form or loading results, show something immediately. INP ends at the next paint, so a quick visual response (a pressed button, a spinner, the menu opening) counts, even if the full result arrives later.

This isn't a trick. It's good design: people trust a page that acknowledges their click right away. Paint the feedback first, then do the slow work after yielding, as in Fix 1.

How do you check that your INP fix worked?

Check the fix in field data, and expect it to take about four weeks to show fully. Search Console's Core Web Vitals report is based on real-user data collected over a 28-day window (opens in new tab), so the number shifts gradually as new visits replace old ones.

1. Re-test the interaction in DevTools straight away to confirm it's faster in the lab.
2. Watch PageSpeed Insights field data for the page over the following weeks.
3. Once enough time has passed, use Validate fix in Search Console's Core Web Vitals report so Google tracks the issue group.

If the number doesn't move, go back to the trace. There's usually a second slow interaction behind the first.

INP is one of three Core Web Vitals. If your pages also fail the others, see how to improve Largest Contentful Paint and how to fix Cumulative Layout Shift.

5.0-star Google rating (24 reviews) · BBB Accredited, A rating

Want your site fixed for you?

If you'd rather hand it off, our website speed optimization services find the slow interactions, fix them in your code and check the result in real-user data.

Website speed optimization · Start a project