ammarmahdi.com online
YYC

Fixing INP on WordPress: less JavaScript, fewer long tasks

4 min read

INP, Interaction to Next Paint, measures how long your page takes to respond when someone taps or clicks. It is the one Core Web Vital you cannot cache or resize your way out of, because it is almost always your JavaScript. Google’s target is 200 milliseconds or less, and anything over 500 milliseconds is officially poor.

I covered what the three vitals are in Core Web Vitals for WordPress. This post is about the hard one: how to find what makes a WordPress page feel sluggish to touch, and how to fix it. The order is always the same. Find the slow interaction, then ship less JavaScript and run it less often.

What INP is actually timing

Before you fix it, know what it measures. Every interaction breaks into three parts:

  • Input delay: the time from the tap until your code can even start, usually because the main thread is busy with something else.
  • Processing time: how long your event handlers take to run.
  • Presentation delay: how long the browser then takes to paint the updated screen.

INP looks at the interactions across the whole visit and reports close to the slowest one, not just the first. That detail matters: a page can load fast and still score badly because a menu, a filter, or an add-to-cart button is slow every single time. Knowing which of the three parts is large tells you where to look, and all three get worse when the main thread is congested with script.

Find the slow interaction first

Do not guess which interaction is slow. Measure it.

  • Start with field data. PageSpeed Insights shows your real INP from Chrome users at the top of the report. That is the number Google actually uses, so it is the one to move.
  • Reproduce it in the lab. Install the Web Vitals Chrome extension, then click around your own pages. It reports the INP of each interaction live, so you can feel out which control is the problem.
  • Record it. Open the Performance panel in Chrome DevTools, record while you trigger the slow interaction, and look for the long task blocking the main thread. That task is your fix list.

The usual WordPress culprits

On WordPress the same handful of things cause most bad INP scores:

  • Page builders. Elementor, Divi, and the rest ship a large JavaScript runtime on every page, whether the page needs it or not.
  • Plugin pile-up. Each plugin can enqueue its own scripts, often jQuery-dependent, on all pages. Twenty plugins each adding a little becomes a lot.
  • Third-party tags. Chat widgets, heavy analytics, ad scripts, and A/B testing tools all run code you do not control on your main thread.
  • The logged-in tax. For logged-in users, the admin bar and the WordPress Heartbeat API add work the front end does not need. Most visitors are logged out, but you, testing the site, are not, so check both.

Ship less JavaScript

The cheapest script is the one you never send.

  • Find scripts that load site-wide but are used on one template, and dequeue them elsewhere with wp_dequeue_script (or a performance plugin’s per-page asset controls).
  • Be honest about page builders. If a page is mostly text, it does not need a builder’s full runtime.
  • Replace a heavy plugin with a lighter one, or with a few lines of code, when it loads far more than its job requires. I have watched a single contact form plugin load a large bundle on every page of a site to power one form on the contact page.

Run what is left less often

You cannot remove everything, so the rest is about not blocking the main thread when the user wants to interact.

  • Delay non-critical scripts until interaction. Many third-party tags, like chat and some analytics, can wait until the user scrolls or clicks. Most caching and optimization plugins offer a delay-until-interaction option, and it is one of the biggest INP wins available on WordPress.
  • Defer what is not needed for the first paint so it does not run while the page is still settling.
  • Break up long tasks. A long task is any single piece of main-thread work over 50 milliseconds, and while it runs, taps just queue up behind it. Code you own can yield to the main thread between chunks so the browser can respond in the gaps. You usually cannot edit a plugin’s code, which is exactly why removing and delaying scripts does more on WordPress than trying to micro-optimize them.

Why it is worth the effort

INP is the vital users actually feel. A page that responds the instant you touch it feels well built, and one that lags feels broken, even at the same load speed. It shows up in the business numbers too: when the retailer Trendyol cut their INP by about half, their click-through rate rose around one percent.

So measure first, find the one interaction dragging your score, and spend your effort there. On WordPress that almost always means sending less JavaScript and running what remains at a better time.

For what LCP and CLS measure alongside INP, see Core Web Vitals for WordPress, and for the whole performance playbook, how to actually speed up a WordPress site.