Originally published on WP Speed Audits.

How to Improve INP in WordPress (2026 Guide)

Your PageSpeed score looks decent, your images are optimized, caching is on — but Google Search Console still flags poor INP on mobile. Sound familiar?

INP (Interaction to Next Paint) became an official Core Web Vital in March 2024, replacing First Input Delay. It measures something caching alone cannot fix: how quickly your site responds when a visitor actually interacts with it — taps a menu, clicks a button, types in a search box.

This guide walks you through measuring INP properly, finding exactly what is slowing down interactions on your WordPress site, and fixing it in order of impact. No fluff, no invented numbers — just the practical method.

What INP Actually Measures (in 60 Seconds)

Every time a visitor interacts with your page — a click, a tap, a keypress — the browser has to run JavaScript, recalculate styles and layout, and paint the next frame. INP measures the delay between the interaction and that next painted frame.

Google's thresholds are straightforward:

• Good: under 200 milliseconds
• Needs improvement: 200–500 milliseconds
• Poor: over 500 milliseconds

Here is the part that trips people up: Google does not average your interactions. It looks at nearly the worst ones (technically the 98th percentile). That means a single slow interaction — one heavy dropdown menu, one laggy add-to-cart button — can tank your whole page's INP score, even if everything else feels instant.

Why does INP matter? Because it is a ranking-relevant Core Web Vital, and because it measures what visitors actually feel. A site can load fast and still feel broken if every tap takes half a second to respond.

Step 1: Measure INP Properly

Before fixing anything, get a trustworthy measurement. INP is trickier to measure than load metrics because it needs real interactions — a lab test that just loads the page may report "no data."

Use these in order:

1. Google Search Console → Core Web Vitals report. This shows your real-world INP status across your site, based on actual Chrome visitors. If it says "poor," believe it — this is the data Google uses.
2. PageSpeed Insights → field data section. Look at the "Discover what your real users are experiencing" block. It shows INP from the Chrome User Experience Report (CrUX). Note that field data lags by about 28 days — fixes take time to show up here.
3. Chrome DevTools → Performance panel. Open your page, start a recording, click around (menu, buttons, forms), then stop. Look for long tasks — the yellow/red blocks on the main thread. Click one to see exactly which script caused it. This is how you find culprits, not just scores.
4. The web-vitals JavaScript library (for developers). If you want ongoing real-user monitoring, this tiny library can log INP to your analytics. Optional, but powerful.

What not to rely on: a single lab score, or your own fast desktop. INP problems live overwhelmingly on mid-range mobile phones, where the same JavaScript takes several times longer to run.

Step 2: Find What Is Slowing Down Interactions

Record a DevTools Performance trace while interacting with the page, then look at the Bottom-Up or Call Tree view sorted by total time. The scripts at the top are your suspects.

On WordPress sites, the usual culprits are remarkably consistent:

• Page builder JavaScript. Elementor, Divi and similar builders load large JS bundles on every page — even pages barely using their widgets. Frontend animation and motion effects are especially expensive.
• Sliders, carousels and popups. Each one adds its own script, and they often initialize on page load whether visible or not.
• Chat widgets and third-party embeds. Live chat, review widgets, social feeds — these are some of the heaviest scripts on the modern web, and they compete for the main thread exactly when the visitor tries to interact.
• Cookie consent banners with heavy JavaScript that blocks or delays everything behind them.
• Theme scripts that were written years ago and never slimmed down — jQuery-era menu and slider code is a classic.
• Too many plugins each adding a small frontend script. Individually harmless; collectively a traffic jam on the main thread.
• A bloated DOM. Page builders nest elements deeply (div inside div inside div). Every interaction forces the browser to recalculate more of the page. As a rough guide, pages with several thousand DOM nodes start paying a real interactivity tax.

Note what is not on this list: your images, your caching plugin's page cache, your CDN. Those affect loading metrics (LCP), not interaction responsiveness. If someone tells you "just install a caching plugin" for INP, they are solving the wrong problem.

Step 3: Fix INP in Order of Impact

Fix 1: Cut JavaScript weight (biggest win for most sites)

Every kilobyte of JavaScript is main-thread work on your visitor's phone. Audit ruthlessly:

• Deactivate plugins you do not need, especially ones adding frontend scripts (old sliders, unused social sharing, "nice to have" widgets).
• Unload scripts per page. Tools like Perfmatters or Asset CleanUp let you disable specific scripts on pages that do not need them — e.g., the contact-form script loading on every blog post, or slider code on pages with no slider. This is one of the highest-ROI changes you can make.
• Replace heavy widgets with lighter alternatives: a native HTML/CSS accordion instead of a JavaScript one, a static testimonial grid instead of a carousel.

Fix 2: Defer or delay non-critical JavaScript — carefully

Deferring JavaScript (load after the page renders) and delaying it (load only on first user interaction) can dramatically cut main-thread work during load. Most optimization plugins — WP Rocket, FlyingPress, LiteSpeed Cache, Perfmatters — offer these toggles.

The critical warning: delaying everything can make your site feel less responsive, not more. If your navigation menu, search box or add-to-cart button depends on a delayed script, visitors will tap and nothing will happen until the script loads — which is exactly the kind of poor interaction INP punishes.

The safe method:

1. Enable delay/defer for JavaScript in general.
2. Immediately exclude interactive scripts: menu/navigation, search, cart and checkout, cookie consent accept buttons, form validation.
3. Test as a logged-out visitor on a real phone: tap the menu, open search, add to cart. If anything hesitates, its script needs excluding.

Fix 3: Tame third-party scripts

Third parties are the worst INP offenders because you cannot optimize their code — you can only control when it loads:

• Delay chat widgets until user interaction (most chat tools and optimization plugins support this). Nobody needs live chat in the first 3 seconds.
• Facade-embed videos and social feeds. Load a lightweight placeholder image and only load the real embed when clicked. A YouTube embed can cost megabytes of JavaScript; a facade costs almost nothing.
• Self-host where possible. Analytics and font files served from your own domain (or CDN) avoid extra DNS lookups and connections.
• Audit with DevTools' coverage or a third-party tracker to find scripts you forgot about — old marketing pixels are notorious.

Fix 4: Put your DOM on a diet

Open DevTools, run document.getElementsByTagName('*').length in the console. If the number is in the thousands on a simple page, your builder is generating bloat:

• Prefer container-based layouts over nested sections and columns.
• Limit widgets per page — every widget is markup plus usually JavaScript.
• Remove hidden-but-loaded elements (sliders with 10 slides where 1 shows, mega menus with hundreds of links on mobile).

Fix 5: Help the main thread

Some of this is developer territory, but worth knowing:

• Keep animations to transform and opacity only — these do not trigger layout recalculations.
• Avoid code that forces synchronous layout (reading layout properties in loops) — this is called layout thrashing and it murders INP.
• Break up unavoidable heavy work with setTimeout or requestIdleCallback so the browser can paint between chunks.

If you are not a developer, Fixes 1–4 will still solve the large majority of WordPress INP problems. Hire a developer only for what remains.

Fix 6: Strengthen the server side (supporting role)

Faster Time to First Byte does not directly fix INP, but a snappy server means the browser starts its work sooner and dynamic interactions (search, filters, cart updates) complete faster:

• Run PHP 8.x with OPcache enabled — older PHP versions are measurably slower at executing WordPress.
• Enable an object cache (Redis or Memcached) so repeated database queries do not repeat work. This shines for logged-in users and dynamic pages, which page caching cannot help. Our Redis setup guide walks through it.
• Choose hosting with enough PHP workers — too few workers and interactions queue up under traffic.

Step 4: Verify the Fix (Without Fooling Yourself)

1. Immediate check: re-record a DevTools Performance trace and confirm the long tasks are gone and interactions feel instant on a mid-range phone (use DevTools device emulation with CPU throttling for honesty).
2. Real-user check: if you installed RUM (the web-vitals library), watch INP trend down over days.
3. Official check: wait for Search Console and PageSpeed field data to update — remember the ~28-day CrUX window. Do not panic if week one still shows "poor."

And do not chase a perfect lab number at the expense of real functionality. An INP of 180ms on a site where everything works beats 120ms on a site with a broken menu.

What Will NOT Fix INP

Save yourself some time — these are common dead ends:

• Page caching alone. Page cache speeds up HTML delivery (great for LCP and TTFB), but INP happens after the page loads, in the JavaScript layer. Caching does not make your menu respond faster.
• Image optimization. Crucial for LCP, nearly irrelevant for INP.
• Installing another optimization plugin without removing the heavy scripts. Plugins do not cancel each other out — the bloat stays.
• A CDN. Wonderful for delivery speed worldwide; does not slim your JavaScript.

Frequently Asked Questions

What is a good INP score for WordPress?

Under 200 milliseconds is "good" by Google's thresholds, 200–500ms "needs improvement," and over 500ms "poor." Aim for under 200ms on mobile — that is where most WordPress INP failures happen, because phones have slower processors running the same JavaScript as desktops.

Why is my INP poor on mobile but fine on desktop?

Mobile CPUs are much slower than desktop ones, so identical JavaScript takes several times longer to execute on a phone. This is the single most common INP pattern on WordPress: a page builder and a few third-party scripts that feel fine on your laptop create long tasks on a mid-range Android device. Fix it by cutting JavaScript weight, not by testing only on desktop.

Does delaying JavaScript improve or hurt INP?

It can do either — which is why this setting needs testing. Delaying non-critical scripts frees the main thread and usually improves INP. But if you delay scripts that power interactive elements (menus, search, cart), tapping those elements does nothing until the script loads, which hurts INP. Always exclude interactive scripts from delaying and test every tap as a logged-out visitor.

How long until Search Console shows my INP improvement?

Google's field data (CrUX) aggregates roughly 28 days of real visits, so Search Console and PageSpeed Insights field data lag behind your fix by about a month. Use DevTools traces and real-user monitoring for immediate feedback, and be patient with the official reports.

Do I need a developer to fix INP?

Usually not. The fixes that solve most WordPress INP problems — removing heavy plugins, unloading unused scripts per page, delaying third-party widgets, simplifying builder layouts — are all settings in optimization plugins, no code required. Bring in a developer only if DevTools points at custom theme or plugin code with genuine long-task problems.

The Bottom Line

INP is the Core Web Vital that caching cannot fix, because it lives in your JavaScript, not your HTML delivery. The winning formula is simple: measure with real data, find the heavy scripts with DevTools, cut what you do not need, delay what is not critical, and protect interactivity while you do it.

Work through the fixes in order, verify on a real phone, and give field data its month to catch up. Your visitors — and Google — will feel the difference with every tap.