How to Fix “Interaction to Next Paint (INP) Issue: Longer Than 200ms” in WordPress

Leave a Comment / SEO Basics, WordPress Tutorials
WordPress Interaction to Next Paint INP Fix Under 200ms Speed Dashboard

Don’t Panic About That Search Console Email

Disclosure: this post contains affiliate links. If you buy through one, we may earn a small commission at no extra cost to you.

If you landed here because Google Search Console flagged “INP issue: longer than 200ms (mobile)” on your WordPress site, take a breath first. This doesn’t mean your rankings are about to collapse, and it doesn’t mean you did anything wrong.

When Google folded Interaction to Next Paint into Core Web Vitals, a lot of WordPress sites that scored fine under the old First Input Delay metric suddenly turned up red. I went through that exact scramble on my own sites — checking Search Console, seeing a wall of “Poor” URLs, and wondering what had actually changed overnight. Nothing broke. The ruler just got stricter.

The fix doesn’t require custom development work or an expensive CDN. After diagnosing this issue across a long list of client WordPress sites — everything from bloated Elementor builds to ad-heavy blogs — the same handful of causes keep showing up, and the same five fixes keep resolving them. That’s what this guide walks through: what INP actually measures, why some popular “speed hacks” quietly make it worse, how to find the exact script causing your slowdown, and the fixes that get sites back into the green.

What Interaction to Next Paint Actually Measures

First Input Delay only clocked the wait before the browser started responding to a click. INP measures the full round trip: from the moment someone taps a button, opens a menu, or presses a key, to the moment the browser actually paints the visual result on screen.

That round trip breaks into three phases:

  1. Input delay — the gap between the tap and the browser picking up the event. This balloons when the main thread is busy with something else, like a heavy ad script loading.
  2. Processing time — how long your JavaScript takes to run once it starts. A bloated Elementor popup script adds directly to this.
  3. Presentation delay — the time the browser needs to recalculate layout and paint the new pixels, such as a mobile menu sliding open.

Google takes the single slowest interaction a visitor has on your page during their session and uses that as your INP score — not an average. One sluggish tap on a bloated page can sink the whole score.

Google’s bar is 200 milliseconds or under for “good.” On a desktop that’s generous. On the mid-range Android phone Google tests with, it’s tight: a WordPress site running Elementor or Divi alongside Google Analytics, AdSense, and a few other third-party scripts can easily eat that entire budget just deciding how to respond to a tap, before anything even paints.

Why Common Speed Hacks Make INP Worse

If you’ve already flipped on a caching plugin’s speed settings and your INP went up instead of down, you’re not imagining it. Two popular “optimizations” tend to backfire specifically on this metric.

Blind JavaScript delay. For years the standard WordPress speed advice was “delay JavaScript execution until the user interacts,” and plugins like WP Rocket and LiteSpeed Cache turned it into a single toggle. The problem: when a visitor taps your mobile menu, that tap is the interaction the browser was waiting for. It now has to fetch the delayed script, parse it, run it, and only then open the menu — often 400 to 600 milliseconds, all counted against your INP. The setting that was supposed to speed up the page quietly created the exact delay Google is penalizing.

Bloated page-builder markup. Every interaction that changes what’s on screen forces the browser to recalculate layout for the DOM elements affected. Page builders that wrap a single line of text in four or five nested

tags can push a page’s total node count past 1,500. Tap a hamburger menu on a DOM that size, and the browser has a lot more to recalculate before it can paint — which shows up as presentation delay.

Find the Culprit Script First, With Chrome DevTools

Before changing any settings, find out which script is actually causing the delay. Guessing wastes time and risks breaking something that wasn’t the problem.

  1. Open your site in Chrome, right-click anywhere on the page, and choose Inspect.
  2. Switch to the Performance tab.
  3. Check the Web Vitals box (and optionally Screenshots).
  4. Click Record, then interact with the page the way a real visitor would — tap the mobile menu, open an accordion, click “Load more.”
  5. Click Stop to generate the trace.

In the resulting profile, look at the Interactions track first: Chrome marks any interaction over 200ms with a red warning triangle. Below it, the Main thread track shows red-striped blocks wherever a “long task” — JavaScript running for more than 50ms — held up the thread. Click the long task sitting under your flagged interaction, then open the Bottom-Up tab at the bottom of the panel. That view names the actual file responsible — often something like elementor-frontend.min.js, an ad network’s script, or a cookie-consent banner.

Five Fixes That Actually Move Your INP Score

With the culprit identified, here’s what consistently works.

If PageSpeed Insights also flagged “Minimize main-thread work” alongside your INP warning, that’s not a separate problem — it’s the same root cause viewed through a different report. Each fix below reduces main-thread work directly: fewer scripts running at all (Fix 1), fewer scripts forced to load at the worst possible moment (Fix 2), animation handed off to the GPU instead of the main thread (Fix 3), less uninvited third-party JavaScript (Fix 4), and a lighter DOM for the browser to recalculate on every tap (Fix 5).

1. Dequeue scripts you don’t need, defer the ones you do

If a script isn’t used on a given page, don’t load it there. A lightweight tool like Perfmatters adds a Script Manager that lets you disable plugin scripts — a contact form, a WooCommerce block, a slider — on templates that don’t use them, and set Defer on scripts that do need to load. Deferring lets HTML parsing continue without blocking the main thread, without triggering the touch-delay problem described above.

Impact: High · Typically visible in CrUX data within 1–2 weeks.

  1. Install Perfmatters, then open Perfmatters → Script Manager from the admin bar while viewing any front-end page — it lists every CSS/JS file actually loaded on that page, grouped by plugin.
  2. For a script that’s irrelevant to the page you’re viewing (a contact-form script on a page with no form, a slider script on a page with no slider), click its gear icon and set it to Disabled → Everywhere except these pages, and name the pages that do need it.
  3. For a script that has to run but doesn’t need to block the first paint, toggle Defer instead of disabling it.
  4. Script Manager works per template, not site-wide — repeat on your homepage, a post, and a category page, since each tends to load a different mix of plugin scripts.

2. Exclude navigation scripts from JavaScript delay

If you’re using “Delay JavaScript Execution” in WP Rocket or a similar plugin, carve out an exception for anything tied to your menu or navigation. In WP Rocket: Settings → File Optimization → Delay JavaScript Execution → Excluded JavaScript Files, then add your theme’s menu scripts, e.g. /themes/astra/assets/js/, /generatepress/assets/js/menu.min.js, and your jQuery file pattern. That keeps the menu script already parsed and ready the instant someone taps it, instead of loading it on demand.

Impact: High — this single setting resolves the touch-delay problem for most sites · Visible in 1–2 weeks.

  1. In WP Rocket, go to Settings → File Optimization → JavaScript, and confirm Delay JavaScript execution is checked.
  2. Scroll to Excluded JavaScript Files and add your theme’s menu and navigation scripts, one path per line (adjust to your theme):
/themes/astra/assets/js/
/generatepress/assets/js/menu.min.js
jquery-?([0-9.]+)?(.min)?.js
  1. Save changes and clear your cache so the new exclusion list takes effect.
  2. Running FlyingPress instead: the equivalent is Settings → Delay JS execution → Excluded scripts, using the same file patterns.
  3. Re-open Chrome DevTools’ Performance panel (from the diagnostic steps above) and tap the mobile menu again — it should now respond without the earlier warning triangle.

3. Switch to CSS-driven mobile menus

Mobile menus are the single most common INP failure point on WordPress blogs. Themes like Astra and GeneratePress animate their menus with pure CSS transforms rather than jQuery, which hands the animation off to the GPU and leaves the main thread free. Pair that with a clean toggle button — no unnecessary nested SVGs or wrapper elements.

Impact: Medium-high · Visible immediately in DevTools, reflected in CrUX within 1–2 weeks.

  1. Open your mobile menu, right-click it in DevTools’ Elements panel, and check the Computed tab while it opens. If left, margin-left, or width are the properties changing, that’s forcing a layout recalculation on every frame — not GPU-accelerated.
  2. On Astra or GeneratePress, this is rarely an issue by default; it usually shows up when a third-party menu plugin or a page-builder-made header overrides the theme’s menu with its own jQuery slide animation.
  3. If you control the CSS, swap left/margin-left transitions for transform: translateX(...) and add will-change: transform — this moves the animation off the main thread entirely.

4. Load ad scripts after the page paints, not before

Ad networks are frequent sources of long tasks. If you run Mediavine or Raptive, turn on their mobile-speed optimization settings in your publisher dashboard. If you’re on Google AdSense directly, avoid loading adsbygoogle.js synchronously in the ; load it after the main content paints, or tie its initialization to scroll rather than the first tap.

Impact: Medium · Visible in 1–2 weeks once dashboard settings propagate.

  1. Mediavine: in your Mediavine dashboard, go to Settings → Site Settings → Ad Settings and enable Optimize for Mobile Speed.
  2. Raptive (formerly AdThrive): in the Ads Manager, open Settings → Performance and turn on lazy loading plus any INP- or Core Web Vitals-specific performance mode offered.
  3. Direct AdSense: remove any synchronous