How to Fix INP on WordPress: Make Your Site Respond Instantly

By Masuma Khatun · August 20, 2026 · 4 min read

You tap a menu button and nothing happens for half a second. You open a product filter and the page freezes. That lag is exactly what Interaction to Next Paint, or INP, is designed to catch.

INP became a Core Web Vital in March 2024, replacing First Input Delay. Unlike its predecessor, which only looked at the first interaction, INP considers the responsiveness of all the interactions during a visit and reports a value close to the worst one. A good INP is 200 milliseconds or less. Above 500 milliseconds is poor.

What INP Actually Measures

When a visitor clicks, taps or presses a key, three things happen: the browser waits to start handling the event, your code runs, and the browser paints the next frame. INP is the time from the interaction to that next paint. If the main thread is busy running other JavaScript, every one of those steps gets longer.

That is why INP problems are almost always JavaScript problems. Your server speed barely matters here. What matters is how much script runs in the visitor’s browser and how long it blocks the main thread.

Common Causes on WordPress

  • Third-party scripts such as chat widgets, tag managers, heat-mapping tools, ad networks and social feeds.
  • Page builders and add-on packs that load large scripts on every page.
  • Sliders, popups and animation libraries running continuously.
  • Large DOM trees with thousands of elements, which make every layout update slower.
  • Filters, search boxes and cart widgets that run heavy code on every keystroke or click.

Step 1: Find the Slow Interactions

Start with field data. In PageSpeed Insights and Search Console, check whether INP is failing on mobile, which is the usual case. Then reproduce it. Install the Web Vitals extension for Chrome, click around your page and watch for slow interactions. For deeper analysis, record a trace in the Chrome DevTools Performance panel and look for long tasks, which are blocks of work longer than 50 milliseconds.

Step 2: Remove What You Do Not Need

The fastest script is the one that never loads. Audit every plugin and third-party tag and ask whether it earns its place. A heat-map tool you checked once last year, a second analytics package or an unused social feed can quietly add hundreds of milliseconds. My guide to auditing plugins shows how.

Step 3: Load Scripts Only Where They Are Needed

A contact form plugin does not need to load on your blog posts. A slider script does not need to run on pages without a slider. Use an asset manager to disable scripts and styles per page or per post type. Test each change, because disabling the wrong file will break a feature.

Step 4: Defer and Delay Non-Critical JavaScript

Deferring tells the browser to run a script after the page has been parsed. Delaying goes further and waits for the first user interaction before loading things like chat widgets. This keeps the main thread free during the moments that matter. Always check the result on key pages such as checkout, because some scripts break when delayed.

Step 5: Break Up Long Tasks

If you or a developer wrote custom code, split big loops into smaller chunks and yield back to the browser between them. Avoid running expensive work directly inside click or input handlers. Move non-urgent work, such as analytics calls, to after the next paint.

Step 6: Reduce DOM Size

Pages with deeply nested containers and thousands of elements are slow to update. Simplify your layouts, avoid stacking many wrapper sections and paginate long lists instead of loading everything at once. Lean block-based layouts usually produce far smaller DOMs than heavy page builder structures.

Step 7: Make Interactions Give Instant Feedback

Even when work takes time, show something immediately. A pressed state on a button, a loading indicator or an opened menu frame tells the visitor the tap registered, and it improves the measured result because the next paint happens sooner.

Watch Out for These Traps

  • Do not rely on a single lab test. Lighthouse does not measure INP directly, so use field data and real interaction testing.
  • Do not delay every script blindly. Anything the page needs to function should still load.
  • Do not forget to re-test after plugin updates, which can reintroduce heavy scripts.

What Results to Expect

Most WordPress sites can bring INP into the good range by removing unnecessary third-party code, trimming plugins and deferring the rest. Stores and membership sites with complex interactions need more careful work.

If your INP is stuck above 200 milliseconds and you are not sure which script is responsible, get in touch and I will trace it for you. You can also read how INP fits with the other metrics in my Core Web Vitals guide.

Masuma Khatun, WordPress speed optimization expert
Written by

Masuma Khatun

Masuma is a WordPress page speed optimization expert with 9+ years of WordPress experience. For the past 3 years she has helped 100+ clients turn slow, frustrating websites into fast, high-performing ones without breaking their design or functionality.

More about Masuma →

Keep Reading

Want Your Site to Pass Core Web Vitals?

Get a free, no-obligation audit with specific recommendations to make your WordPress site faster.