In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the official Core Web Vital for responsiveness. Three years later, INP is still the metric that trips up most WordPress sites — not because WordPress is slow by design, but because plugins, themes, and third-party scripts stack JavaScript onto the main thread until simple clicks and taps take half a second or more.
This guide is the step-by-step process we actually run in the lab: how to measure INP, find the interaction that’s failing, and fix it at the code level — without disabling plugins blindly or switching themes out of superstition.
What Is INP and Why Does It Matter for WordPress?
INP measures the time between a user’s interaction (click, tap, keypress) and the moment the browser paints the next frame in response (Source). It’s reported as the worst (p95-ish) interaction a user experiences, not the average, and it’s evaluated at the 75th percentile of page loads in the field.
The official thresholds:
| Rating | INP value |
|---|---|
| Good | ≤ 200 ms |
| Needs improvement | 200–500 ms |
| Poor | > 500 ms |
Why WordPress struggles with INP more than most platforms: the average install runs 20–40 plugins and a page-builder theme, each enqueueing scripts and styles on every page — often jQuery-dependent, often render-blocking. Every <script> becomes work on the main thread, and the main thread is the exact resource INP measures.
Lab example: we took a sample WordPress site from 320 ms to 180 ms INP — crossing the “good” threshold — using nothing more than the fixes below. No new plugin required.
How to Measure INP on Your WordPress Site
Before changing anything, measure. INP is a field metric — lab tools like Lighthouse approximate it, but real users give you the truth:
- CrUX / PageSpeed Insights — search your domain; the “Interaction to next paint” row in field data shows your real-world 75th-percentile INP over the last 28 days.
- Web Vitals browser extension — click around your site live; each interaction records its latency with a breakdown.
- Chrome DevTools → Performance recorder — record a real session (menu open, form fill, checkout step) and look at the Main thread track: long tasks over 50 ms are the smoking gun.
Pro tip: test the interactions your visitors actually use. A blog visitor scrolls; a WooCommerce visitor taps “Add to cart” and opens the mini-cart. Optimize the interaction that matters, not the one that’s easiest to fix. Looking for a professional audit? Contact us.
The 5 Most Common INP Killers on WordPress
1. Plugin and theme JavaScript on every page load
Most plugins enqueue their scripts site-wide (wp_enqueue_script with no conditional). A slider that only runs on the homepage still ships its 80 KB of JS to your checkout. Fix: scope scripts with is_page(), is_product(), or wp_register_script + frontend conditions, and use defer for everything that doesn’t run before first paint.
2. jQuery dependence and legacy handlers
Thousands of plugins still ship jQuery. Every jQuery plugin creates long tasks on interaction. Fix: audit with wp_enqueue_script logs, replace $(document).ready() blocks with native DOM APIs (DOMContentLoaded), and where jQuery is unavoidable, load it once in the footer and remove jquery-migrate.
3. Third-party scripts and tracking tags
Analytics, chat widgets, retargeting pixels, reviews carousels — each one executes on the main thread when it loads and often again on interaction. A single slow tag can add 100+ ms to a click. Fix: self-host analytics (e.g., Plausible, or proxy GA4), load chat widgets only after user intent (scroll or click), and add fetchpriority="low" to below-the-fold embeds.
4. Slow TTFB and a saturated main thread
Here’s the part most guides miss: if Time to First Byte is 800 ms, every subsequent script and image competes with your user’s first interaction. Server-side latency directly inflates INP. Fix: page caching, object caching, and a fast host — the same engineering we covered in Redis vs LiteSpeed Object Cache for WooCommerce and Cloudflare APO vs WP Rocket. Get TTFB under 200 ms and the main thread stops being a parking lot.
5. Large DOM and layout thrashing
A 3,000-node DOM means any getBoundingClientRect() or style read forces expensive reflows. Fix: keep DOM under ~1,400 nodes, avoid forcing synchronous layout in event handlers, use will-change sparingly, and batch your DOM writes with requestAnimationFrame.
The Fix Pipeline: What We Do in the Lab
Here’s the exact workflow we run when a site fails INP — follow it top to bottom:
- Step 1 — Identify the slow interaction (day 1). Measure in field + DevTools. Write down: which element, which phase (input delay / processing / presentation). 90% of the time you’ll find one long task from a plugin handler.
- Step 2 — Trim the interaction path (day 1–2). Disable plugins one by one in a staging clone, re-measure on each. If INP drops 100 ms when you deactivate tag-manager-related or slider plugins — you found your culprit. Keep it deactivated, replace it, or scope its scripts.
- Step 3 — Defer, split, enqueue smarter (day 2–3). Add
deferto all non-critical scripts,wp_deregister_script+wp_register_scriptfor unused dependencies, and split the bundle so only the interaction-relevant code loads on the pages that need it. If you run a page builder, disable its scripts on pages that don’t use it. - Step 4 — Fix the server side (day 3–4). Get page cache running, add object cache (Redis or LiteSpeed per our earlier head-to-head), and make sure your CDN isn’t fighting your cache rules — a misconfigured “Cache Everything” rule can turn a fast site into a slow one, as our WooCommerce checkout cache post-mortem shows.
- Step 5 — Re-test in the field (day 14+). Lab numbers lie; CrUX data doesn’t. After changes, monitor the 75th-percentile INP in Search Console for 2–4 weeks. If a fix didn’t move the field number, revert it.
Special Case: INP on WooCommerce Checkouts
Interaction-heavy pages — mini-cart, checkout, payment forms — are where INP failure hurts revenue directly. A slow “Place order” response is cart abandonment. Three checkout-specific rules: (1) never load homepage sliders or blog widgets on checkout; (2) scope WooCommerce scripts to WooCommerce pages with is_checkout(), is_cart(); (3) make sure payment-gateway scripts (Stripe, PayPal) load only on checkout, with the SDK deferred. And critically — verify caching never interferes with checkout flows, the exact failure we documented in How to Stop Cloudflare From Caching Your WooCommerce Checkout.
FAQ
- Is INP a ranking factor?
- Yes — since March 2024 INP is a Core Web Vital, meaning it contributes to the page experience signal Google uses in ranking, alongside LCP and CLS (Source).
- What is a good INP score?
- 200 ms or less at the 75th percentile of real-user loads. Between 200 and 500 ms is “needs improvement”; above 500 ms is “poor”.
- Why is my INP still slow after I installed a caching plugin?
- Caching improves TTFB and LCP, but INP is driven by client-side JavaScript. If your main thread is busy with plugin and tag scripts, no amount of caching will fix it — you need Steps 2–3 above.
- Does removing jQuery fix INP?
- Often dramatically. jQuery adds overhead to every handler; removing it (or at least
jquery-migrate) frequently removes 50–150 ms from interactions. Test it on staging first — some plugins hard-depend on it. - What’s the difference between FID and INP?
- FID measured only the initial input delay of the first interaction; INP measures the full duration (input → processing → presentation) of every significant interaction. INP is a much stricter, more realistic test of responsiveness.
- How long does it take to see INP improve in the field?
- CrUX aggregates 28 days of real Chrome data, so allow 2–4 weeks for an improvement to show up in PageSpeed Insights. Lab tools (Lighthouse, DevTools) show changes instantly — those are what you use to iterate.