Interaction to Next Paint (INP) measures something LCP and CLS don’t: how a page feels once a visitor starts clicking, tapping, and typing. A page can load quickly and sit visually still, yet still feel sluggish the moment someone opens a menu or submits a form. Alongside Cumulative Layout Shift in WordPress: How to Find and Fix CLS, INP rounds out the three metrics in the Core Web Vitals category. This guide covers what INP measures, how to identify the interactions dragging it down, and which WordPress-specific fixes are safe to apply.
What Interaction to Next Paint measures
INP measures the time between a user interaction, a mouse click, a tap on a touchscreen, or a key press, and the next moment the browser paints a visual update in response. Unlike its predecessor metric, First Input Delay (FID), which only measured the delay before the very first interaction’s event handler began running, INP evaluates interactions across the entire page visit and reports a value representative of the worst typical interaction, giving a far more complete picture of responsiveness throughout a session. Only discrete interactions, clicks, taps, and key presses, are observed for INP; scrolling and hovering are not included.
Current INP thresholds
As of 2026, Google’s thresholds for INP are: good at 200 milliseconds or less, and poor above 500 milliseconds, with the range in between considered “needs improvement.” As with other Core Web Vitals, this is assessed at the 75th percentile of real user interactions for a given page or origin, meaning three out of four measured interactions need to fall within the “good” range for the page to pass overall.
Field data versus lab diagnostics
INP field data from the Chrome User Experience Report reflects real visitors and is used for the Core Web Vitals assessment. Chrome DevTools records a controlled interaction to investigate why it is slow. As covered in How to Measure WordPress Speed Before Making Any Changes, these two data sources answer different questions, whether a real problem exists, and specifically where the time is going, and both are needed for a complete picture.
Why INP cannot be fully represented by one synthetic test
INP is inherently interaction-dependent: its value depends on which specific interaction a visitor performs, at what point in the page’s lifecycle, and under what device and network conditions. A single Lighthouse or PageSpeed Insights lab run can only simulate a limited set of interactions, and it cannot capture every menu, filter, form field, or button a real visitor might use, nor the wide range of real-world device performance. A comprehensive picture requires combining a handful of manual DevTools tests on the interactions you suspect are slow with the aggregate field data from real visitors over time.
The three INP subparts
Google’s current model breaks each interaction into three sequential phases:
- Input delay: the time between the user’s action and when the browser begins running the relevant event handler. This delay grows when the browser’s main thread is already busy with other work, such as a long-running script, and cannot immediately respond to the interaction.
- Processing time: the time the event handler itself takes to run to completion, including any related JavaScript logic triggered by the interaction.
- Presentation delay: the time between the event handler finishing and the browser actually painting the resulting visual update, which can be affected by layout complexity, DOM size, and the amount of rendering work required.
Input delay is generally outside the direct control of the specific event handler being clicked, since it’s caused by other work already queued on the main thread; processing time and presentation delay are more directly influenced by the code running in response to that specific interaction.
Identifying slow interactions on a WordPress site
Common WordPress-specific interaction types worth testing individually include:
- Opening a mobile navigation menu or dropdown submenu
- Submitting a comment, contact, or newsletter signup form
- Interacting with product filters, sort controls, or search-as-you-type fields
- Operating a slider, carousel, or accordion widget
- Adding an item to a cart or updating quantities on a WooCommerce page
- Opening a modal, lightbox gallery, or cookie-consent banner
Testing each individually, rather than assuming they all behave the same way, matters because a single heavy plugin script attached to just one of these interactions can be responsible for a site’s entire poor INP field score, even if every other interaction is fast.
Diagnosing with Chrome DevTools’ Performance panel
Chrome DevTools’ Performance panel can record a page session while you manually perform a specific interaction, then display the resulting input delay, processing time, and presentation delay for that recorded interaction directly on the timeline. This is the most direct way to confirm which phase is responsible for a slow interaction and, within the processing time phase specifically, which function or script is consuming the most time. The panel’s flame chart view shows the call stack, making it possible to trace a slow interaction back to a specific plugin or theme script rather than guessing.
Long tasks and main-thread blocking
A “long task” is any single piece of JavaScript execution that occupies the browser’s main thread for an extended, uninterrupted period, commonly identified as tasks lasting 50 milliseconds or more. While a task like this is running, the browser cannot respond to any user interaction, including ones that occur partway through, which is what produces the input delay portion of INP. Long tasks are frequently caused by large synchronous scripts, heavy DOM manipulation, or unoptimized third-party embeds executing all at once rather than in smaller, interruptible chunks.
Heavy JavaScript and third-party scripts
Analytics tags, chat widgets, advertising scripts, and social embeds can create long tasks because they run on the page’s main thread. Audit active third-party scripts with the Network and Performance panels before blaming the theme or content plugins.
WordPress plugins and theme scripts
Plugins that attach event handlers to interactive elements, form builders, sliders, mega-menus, live search, and similar features, are common contributors to processing time specifically, since their JavaScript runs directly in response to the interaction being measured. A poorly optimized plugin script that performs unnecessary work on every click (re-querying the DOM repeatedly, recalculating layout values, or making unnecessary network requests) can noticeably worsen INP for that specific interaction, even if the rest of the page performs well.
DOM size and rendering work
A very large DOM (an unusually high number of nested HTML elements) increases the work the browser must do during the presentation delay phase, since style recalculation and layout work scale with the number of elements involved. Page builders that generate deeply nested wrapper elements for every section, row, and column can meaningfully increase DOM size compared to more minimal markup, worth checking if presentation delay shows up as the dominant subpart in DevTools. A large DOM can also affect Largest Contentful Paint‘s element render delay for similar reasons, since both metrics are affected by the same underlying rendering work.
Event handlers and unnecessary work
It’s worth checking whether an interactive element’s event handler is doing more work than the interaction actually requires, for example, recalculating values that haven’t changed, querying the DOM repeatedly instead of caching a reference, or running unrelated code alongside the specific action a visitor triggered. This is generally a theme or plugin code quality issue rather than something a site owner can fix directly, but it’s useful to identify and report to a plugin developer, or to consider as a factor when choosing between competing plugins offering similar functionality.
Breaking up long tasks
Where custom code is involved, breaking a single large task into smaller chunks, yielding control back to the main thread between chunks, allows the browser to respond to interactions that occur partway through a longer operation, rather than making them wait for the entire operation to finish. This is a developer-level technique most relevant to custom theme or plugin code rather than something adjustable through standard WordPress settings, but it’s useful to understand when evaluating whether a specific plugin’s script behavior is contributing to poor INP.
Deferring non-critical JavaScript safely
As covered in WordPress Fonts, CSS, Scripts, and Plugin Weight Explained, deferring scripts that aren’t needed for initial interactivity, using WordPress’s strategy argument for enqueued scripts, or the older wp_script_add_data() approach, can reduce the amount of competing work on the main thread during the page’s early loading window, indirectly helping input delay for early interactions. This should be tested carefully, since deferring a script whose dependents expect it to have already run can break functionality rather than just slow it down.
Reducing plugin-generated front-end scripts
Auditing active plugins for ones that enqueue JavaScript site-wide, rather than only on pages that use their specific functionality, is a practical way to reduce baseline main-thread activity, which in turn reduces the likelihood of input delay on unrelated interactions elsewhere on the page. This overlaps directly with the plugin-weight auditing process described in the fonts and scripts article referenced above.
Testing logged-out and real-user interactions
Always test interactions as a logged-out visitor, since the WordPress admin toolbar and any admin-only scripts add extra main-thread activity that public visitors never encounter. Where possible, test on a mid-range mobile device or a throttled CPU setting in DevTools rather than only a fast development machine, since INP is disproportionately affected by device performance, and a slow interaction on a modest phone may not be reproducible at all on powerful hardware.
Verification after changes
After making a change, re-test the same specific interaction, on the same page, using the same DevTools recording approach as the original diagnosis, to confirm the targeted subpart actually improved. Field data will take longer to reflect the change, since CrUX aggregates over a rolling window; treat the DevTools re-test as immediate confirmation and the Search Console field data as longer-term validation once enough time and traffic have passed.
Common INP optimization mistakes
- Testing only page load performance and never manually testing individual interactions like menus or forms
- Assuming a fast LCP or CLS score means INP is also fine, when they measure entirely different things
- Deferring a script without checking whether other scripts depend on it running at a specific time
- Blaming a theme or plugin without first confirming which specific interaction and which subpart is actually slow
- Testing exclusively on high-end hardware, missing problems that only appear on mid-range mobile devices
- Not testing as a logged-out visitor, which can mask or distort real public-facing performance
Practical INP checklist
- Identify your site’s most common interactive elements: menus, forms, filters, sliders, search
- Test each one individually in Chrome DevTools’ Performance panel, as a logged-out visitor
- Note which of the three subparts, input delay, processing time, or presentation delay, is largest for each slow interaction
- Audit third-party scripts and plugin-enqueued JavaScript for unnecessary site-wide loading
- Check DOM size and nesting depth if presentation delay is the dominant subpart
- Defer non-critical scripts carefully, testing for broken dependencies afterward
- Re-test the same interaction after each change, then confirm with field data over time
Key Takeaways
- INP measures responsiveness across a visitor’s entire session, not just the first interaction, and breaks down into input delay, processing time, and presentation delay.
- Current thresholds are good at 200ms or less and poor above 500ms, assessed at the 75th percentile of real interactions.
- No single lab test can represent INP fully, since it depends on which interaction is performed and under what device conditions; combine manual DevTools testing with field data.
- Long tasks on the main thread, often from third-party scripts or heavy plugin JavaScript, are a common root cause of poor input delay.
- Always test specific interactions individually, as a logged-out visitor, rather than relying only on general page-load metrics.
FAQs
Is INP the same as First Input Delay (FID)?
No. FID only measured the delay before the first interaction’s event handler began running. INP measures across all interactions during a page visit and includes processing time and presentation delay in addition to input delay, giving a more complete picture of responsiveness.
Why does my site score well on PageSpeed Insights but still feel slow when I click things?
PageSpeed Insights’ lab test only simulates page load conditions and a limited interaction set; it may not reproduce the specific interaction, device, or real-world condition causing your slowdown. Manually test the specific interaction in DevTools and check your field data in Search Console for a fuller picture.
Can a single plugin be responsible for a poor INP score?
Yes. A single plugin attaching a heavy event handler to one interactive element, a mega-menu or a live search field, for example, can be entirely responsible for a poor INP score even if the rest of the site performs well.
Does reducing plugins always improve INP?
Not automatically, though it often helps. What matters is whether a specific plugin’s scripts are contributing long tasks or heavy event-handler processing; a lightweight, well-coded plugin may contribute very little, while a single poorly optimized one can dominate the metric.
Should I test INP on a fast development computer or a real phone?
Test on both, but weight real-world mobile testing (or CPU-throttled DevTools testing) more heavily, since INP is strongly affected by device performance, and problems that are invisible on fast hardware are often clearly present on mid-range mobile devices.
