INP Is Google's Newest Pain Metric: How to Diagnose and Fix Interaction Lag
INP Is Google's Newest Pain Metric: How to Diagnose and Fix Interaction Lag
In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) as the Core Web Vital that measures responsiveness. If your site was passing CWV before that date and started failing after, INP is almost certainly the reason. And if your WordPress site has more than a handful of plugins and a page builder, your INP is very likely in "Needs Improvement" or "Poor" territory — even if everything else looks fine.
INP is harder to diagnose than LCP and harder to fix than CLS. It measures something that doesn't show up cleanly in a static performance scan: how your site responds to real user interactions. A menu click, an accordion open, a form field tap — INP captures the delay between the user's input and the browser's next visual response. When that delay is over 200ms, users feel it as lag. When it's over 500ms, it's noticeable enough to drive abandonment.
The reason INP replaced FID is that FID only measured the delay before the browser started processing an input — it didn't measure how long that processing took. INP measures the full interaction: input delay plus processing time plus presentation delay. It's a better proxy for "does this site feel responsive?" and it's significantly harder for a WordPress plugin stack to pass.
Quick Checklist
- Check your INP score in PageSpeed Insights (use mobile field data)
- Open Chrome DevTools → Performance panel → record an interaction
- Look for long tasks (over 50ms) in the Main thread flame chart
- Audit third-party scripts: analytics, chat, and ads are common INP killers
- Check your plugin count and JavaScript payload size in DevTools Network tab
- Test specific interactions: menus, accordions, modals — which feels slow?
- Use web.dev's INP diagnostic guide for step-by-step measurement
What INP Measures and Why It Replaced FID
FID (First Input Delay) measured only the input delay portion of a user interaction — the time between a user's first interaction with a page and when the browser began processing it. If the browser was busy executing JavaScript when the user clicked, FID captured that wait. But it didn't capture how long the browser then took to process the event handler and update the screen. FID could look good on a site that had fast initial response but sluggish subsequent processing.
INP closes that gap. According to web.dev's INP documentation, INP measures the full latency of all interactions during a page visit, then reports the worst or near-worst interaction as the final score. It considers three phases: input delay (waiting for the main thread to be free), processing time (executing event handlers), and presentation delay (rendering and painting the visual update).
INP is also more representative because it measures the entire session, not just the first interaction. A user who has a smooth first click but then triggers a slow interaction when opening a cart drawer gets a poor INP score, even if FID would have been excellent.
The practical implication: FID was relatively easy to pass on WordPress because it only measured one narrow slice of interaction behavior. INP is harder to pass because it surfaces the full cost of JavaScript-heavy pages on every interaction, across the full session.
Google's INP Thresholds
Google's current thresholds, as documented in their Core Web Vitals announcements:
- Good: 200ms or faster
- Needs Improvement: between 200ms and 500ms
- Poor: over 500ms
These are measured at the 75th percentile of all interactions for a given page in the CrUX dataset. This means 75% of interactions for 75% of your users need to be under 200ms for your page to register as "Good" in field data. On a page with a bloated DOM and heavy plugin JavaScript, this is a genuinely difficult bar to clear on mobile.
How to Diagnose INP Issues
Diagnosing INP requires both lab tools (for identifying the specific long tasks) and field data (for confirming which interactions actually affect your real users).
Field Data via CrUX and PageSpeed Insights
Start with PageSpeed Insights. Enter your URL, switch to mobile view, and look at the Field Data section at the top of the results. If your INP is in "Needs Improvement" or "Poor" range in field data, you have a documented problem that Google's ranking system is aware of.
Note the INP value. A score of 250ms to 400ms usually indicates a few specific long tasks causing the problem — these are fixable. A score above 500ms usually indicates systemic JavaScript problems across the page — plugin bloat, DOM bloat, or third-party scripts that need a more structural solution.
PageSpeed Insights also shows which interactions are contributing to your INP in the "Opportunities and Diagnostics" section. Look for "Reduce JavaScript execution time," "Minimize main thread work," and "Avoid long main-thread tasks" — these point directly to the categories of INP problems on your page.
Chrome DevTools Performance Panel
The DevTools Performance panel gives you the granular view you need to identify specific INP culprits.
Open Chrome DevTools (F12), go to the Performance tab, and click the record button. Then perform the interaction that you suspect is slow — open a navigation menu, click an accordion, submit a form. Stop recording after the interaction completes.
In the flame chart that appears, look at the Main thread row. Long tasks appear as red-flagged blocks. These are tasks that took over 50ms to complete. Hover over them to see which function or script is responsible. Common offenders: plugin event handlers, page builder re-render logic, third-party analytics callbacks, and chat widget initialization code.
The Interactions section of the Performance panel (available in newer Chrome versions) shows each interaction and its total latency breakdown, split into input delay, processing time, and presentation delay. This tells you which phase of the interaction is the bottleneck.
Lab Testing vs Real-User INP
Lab testing with Chrome DevTools gives you a controlled environment where you can reproduce and debug specific interactions. But it won't exactly match your field data INP score, because:
Real users have different devices. INP on a mid-range Android phone can be 3x to 5x worse than INP on a developer's MacBook Pro. If your field data INP is 400ms but your DevTools testing on a fast laptop shows 120ms, test with CPU throttling enabled (4x slowdown is a reasonable mobile approximation).
Real users interact in unpredictable sequences. An interaction that's fast in isolation might be slow when it happens after the page has been scrolled, other interactions have been performed, or background JavaScript has been running for several minutes.
For representative lab testing, use Chrome DevTools with 4x CPU throttling and test interactions that your analytics data shows are commonly performed by real users.
The Most Common Causes of INP Problems on WordPress Sites
Heavy JavaScript Payloads from Plugins and Page Builders
WordPress has no native module bundler or dependency resolution system. Each plugin loads its JavaScript independently. A typical WordPress site with 20 plugins might deliver 400KB to 800KB of JavaScript to the browser. That payload has to be parsed and compiled by the JavaScript engine before it can run. On mobile devices, this compilation phase alone can occupy the main thread for 500ms to 2,000ms — and during that time, user interactions are queued rather than processed.
Even after initial load, all that JavaScript remains active in memory. Event listeners from every plugin are attached to DOM elements. When a user interacts with the page, the event must propagate through potentially hundreds of registered handlers. The processing time portion of INP grows with every additional plugin that adds to this handler count.
Page builders compound this further by adding their own component JavaScript — widget initialization, responsive behavior calculations, and animation libraries — on top of the plugin stack.
Long Tasks Blocking the Main Thread
The browser's main thread handles JavaScript execution, DOM manipulation, style calculation, layout, and paint. Because JavaScript is single-threaded, all of these tasks must take turns on the main thread. A long task — anything that runs for more than 50ms — blocks all other tasks, including user interaction processing.
Long tasks on WordPress sites typically come from: plugin initialization code that runs on page load, third-party script initialization (analytics, tag managers, chat), page builder component initialization, and event handler chains triggered by user interactions.
The scheduler APIs that modern JavaScript frameworks use to break long tasks into smaller chunks — scheduler.postTask(), requestIdleCallback(), setTimeout with 0ms delay — are available in WordPress JavaScript, but most plugin authors don't use them. The result is concentrated long task execution that makes your site feel unresponsive.
Third-Party Scripts
Analytics platforms, live chat widgets, advertising networks, A/B testing tools, heat mapping scripts — each of these adds JavaScript that runs on your users' devices. Third-party scripts are a major INP contributor because:
They're not bundled with your page JavaScript, so they can't be tree-shaken or code-split with your build process. They load independently, often with their own timing logic.
Many third-party scripts run heavy initialization code — connecting to external services, setting up event tracking, loading additional scripts. This initialization often runs during or immediately after page load, competing with the main thread precisely when users are likely to start interacting.
Chat widgets are among the worst offenders. A typical live chat widget loads its full library on every page, including pages where no user will ever open the chat. The library initializes, connects to the chat service, and registers interaction handlers — all on the main thread, all adding to your INP exposure.
How to Fix INP: A Prioritized Approach
1. Identify and Defer Non-Critical Third-Party Scripts
The highest-leverage INP fix is usually deferring third-party scripts. Chat widgets, analytics beyond basic page view tracking, A/B testing tools, and ad networks should not load during the critical user interaction window.
Load chat widgets on user intent signals: mouse movement toward the corner where the widget appears, or after 5 seconds of dwell time. Load A/B testing variants synchronously only if they affect above-fold content; for below-fold tests, defer and accept the brief layout flash. Load ad scripts with async and constrain them to specific slots rather than global initialization.
WP Rocket and other caching plugins offer basic script deferral, but they can break plugin functionality if not carefully configured. Test each deferral change in a staging environment.
2. Break Up Long Tasks
Long tasks that block the main thread can often be broken into smaller, schedulable chunks. The browser's scheduler.postTask() API allows you to schedule work at different priorities. For code you can modify (custom theme JavaScript, child theme additions), use setTimeout with 0ms delay to yield the main thread between heavy operations.
For plugin code you can't modify, the practical option is to replace heavy plugins with lighter alternatives. A contact form plugin that loads 80KB of validation JavaScript can often be replaced with a simpler form handler that uses browser-native validation.
3. Reduce JavaScript Bundle Size
Audit your JavaScript payload in Chrome DevTools → Network tab → JS filter. For each large file, identify which plugin or theme generates it. For plugins where you're using a small fraction of their functionality, look for lighter alternatives that don't bring a full library for limited features.
The Coverage tab in Chrome DevTools shows you what percentage of each JavaScript file is actually executed during a typical page session. Files with over 70% unused code are prime candidates for replacement.
4. Address DOM Bloat
High DOM node counts slow down style recalculation on every interaction. If your page builder is generating 3,000+ nodes, the architectural fix is removing the page builder. In the meantime, simplifying page templates — reducing nesting depth, consolidating redundant wrapper elements where possible — can reduce the recalculation cost of each interaction.
How Next.js Handles INP by Design
Next.js addresses INP at the framework level, not through plugins or workarounds.
React's event system is efficient and batches updates to minimize repaints. React 18's concurrent rendering features allow the framework to deprioritize non-urgent work and keep the main thread available for user interactions. Server components move data fetching and rendering to the server, eliminating the client-side JavaScript needed for those operations entirely.
Next.js's build system produces per-route code-split bundles. A user visiting your homepage receives only the JavaScript that the homepage needs — not the JavaScript for your blog, your checkout page, or your contact form. This dramatically reduces the initial JavaScript payload and the amount of code that needs to compile and execute before interactions feel responsive.
Third-party script loading in Next.js is handled through the next/script component, which gives developers explicit control over load strategy: beforeInteractive, afterInteractive, or lazyOnload. The afterInteractive strategy, which defers scripts until after the page is interactive, is the default for analytics and other non-critical scripts. This prevents third-party initialization code from competing with user interactions during the critical early session window.
For sites where INP is the primary Core Web Vital failure, the move to Next.js often produces the most dramatic improvement relative to WordPress optimization. This is because INP on WordPress is typically a systemic problem — too much JavaScript from too many sources with no coordination — rather than a specific problem with one fixable component.
For more context on how architectural decisions affect all three Core Web Vitals, the Core Web Vitals for WordPress post covers LCP, INP, and CLS in a unified framework.
For LCP-specific diagnosis and optimization, see the LCP optimization guide.
Running a Complete INP Diagnostic
Here's the step-by-step process to identify your INP bottleneck before deciding on a fix strategy.
Step 1: Get your field data baseline. Open PageSpeed Insights for your top 5 traffic pages. Record the INP value from the Field Data section. Note which pages have the worst INP — these are your priority targets.
Step 2: Identify your worst interactions in lab testing. Open Chrome DevTools with 4x CPU throttling enabled. On your worst-performing page, perform the interactions that real users commonly take: open the navigation, scroll to a section, click any interactive elements. Use the Performance panel to record these interactions and identify which ones produce the longest tasks.
Step 3: Attribute long tasks to specific scripts. In the flame chart, hover over each long task block to see the call stack. Note the script file name and the function responsible. Cross-reference with your Network panel to identify which plugin or third-party service generated that script.
Step 4: Test removals on staging. For each major long task culprit, test deactivating or deferring that script on a staging site. Measure INP before and after each change. This tells you the actual INP contribution of each script, which guides your prioritization.
Step 5: Evaluate diminishing returns. After the easy wins — deferring third-party scripts, replacing heavy plugins with lighter alternatives — calculate your projected INP. If you can reach "Good" (under 200ms in field data) with WordPress changes, proceed. If your remaining long tasks come from the page builder, core plugin functionality you can't remove, or the WordPress JavaScript architecture itself, you've identified the ceiling.
FAQ
Did INP replace FID as a Core Web Vital?
Yes. Google officially replaced First Input Delay (FID) with Interaction to Next Paint (INP) in March 2024. INP is now one of the three Core Web Vitals that contribute to Google's Page Experience ranking signal, alongside LCP and CLS. FID is no longer a ranking factor. If your performance monitoring still tracks FID as a primary metric, you should update your tooling to focus on INP.
What's a good INP score to target?
Google's "Good" threshold is 200ms or faster at the 75th percentile of interactions, measured from real-user field data. In practice, you should aim for an INP score under 150ms in your field data to give yourself buffer, since field data includes interactions from slower mobile devices and variable network conditions. In controlled lab testing with CPU throttling, targeting under 100ms for your most common interactions gives you a reasonable margin.
How is INP different from FID?
FID measured only the input delay phase — the time between a user's first interaction and when the browser started processing it. It captured whether the main thread was busy when the first input arrived, but not how long the actual processing and rendering took afterward. INP measures the full interaction latency: input delay plus processing time plus presentation delay. It also measures all interactions throughout the session (reporting the worst or near-worst), not just the very first one. INP is harder to pass because it exposes the full cost of JavaScript-heavy pages on every interaction.
Can I fix INP without a full site rebuild?
Yes, in many cases. If your INP failures come primarily from deferrable third-party scripts (chat, analytics, ads) or from one or two specific heavy plugins that can be replaced, targeted fixes within WordPress can get you to "Good." The cases where you can't fix INP within WordPress are when the long tasks come from your page builder's component JavaScript, from core functionality plugins that you can't remove or replace, or from the cumulative effect of 15+ plugins all adding to main thread load simultaneously. The diagnostic process above will tell you which situation you're in.
Do WordPress caching plugins help with INP?
No, not directly. Caching plugins like WP Rocket and W3 Total Cache reduce server response time (TTFB) and can slightly reduce the amount of JavaScript sent to the browser through minification and combination. But INP is a client-side metric — it measures what happens in the user's browser after the page has loaded. Caching has no effect on the long JavaScript tasks that block the main thread, the DOM size that slows style recalculation, or the event handler overhead from multiple plugins. Some caching plugins offer script deferral features that can help INP at the margins, but deferring a large JavaScript payload doesn't eliminate it — it just delays when the browser processes it.
Next Steps
INP is the Core Web Vital most likely to be hurting WordPress sites right now, and it's the hardest to fix without understanding exactly where the interaction lag is coming from. The right first step is a measurement baseline — field data across your key pages, long task attribution in lab testing, and a clear view of which interactions are dragging your score down.
Related posts:
Services: