ArWordPress INP optimisation: find the slow interaction
The archive date follows the period covered. This retrospective was added on November 3, 2026.
A WordPress page can look fully loaded and still feel slow when someone opens a menu, filters products or starts filling in a form. For that experience, the important question is what happens after an interaction.
The March 2024 change
On March 12, 2024, Interaction to Next Paint replaced First Input Delay as a Core Web Vital. INP assesses responsiveness across qualifying interactions during a visit. This article looks back at the change and applies guidance reviewed in 2026 to WordPress development.
The INP reference defines a good result as 200 milliseconds or less at the 75th percentile, assessed separately for mobile and desktop. INP concerns the browser’s response through the next paint; it is not the total time for a payment or API request to finish.
Begin with a visitor journey
Choose the interactions that matter to the business. For a lead-generation site, that could be the navigation, a service selector and form validation. For a shop, it could be product filters, variation selection and the cart drawer.
Write down the expected visible response. A form should acknowledge a submission while the server works. A filter should clearly show its state. This separates slow browser work from a long-running operation that needs better feedback.
Use field evidence, then reproduce the problem
Google’s INP optimisation guide recommends finding slow interactions in field data and diagnosing them in the lab. PageSpeed Insights can show available Chrome User Experience Report data; richer real-user monitoring can help identify which interaction caused the delay. A small site may not have enough public field data.
Our suggested investigation captures the page, device class, interaction and surrounding state. Was the visitor opening the menu during initial loading? Had a third-party widget just inserted content? A reproducible sequence is much more useful to a developer than a screenshot of one score.
Trace before changing plugins
On WordPress, we would inspect theme handlers, plugin scripts, experimentation code and third-party tags together. The bottleneck may sit outside the component the visitor clicked. A menu can appear unresponsive because unrelated work is occupying the browser’s main thread.
- Look for repeated event listeners after dynamic content updates.
- Check whether filtering rebuilds far more of the page than necessary.
- Inspect layout work caused by reading and changing geometry repeatedly.
- Review scripts that run on every page despite serving only one feature.
These are diagnostic questions, not a rule to remove every plugin. A focused fix to one handler may preserve the site’s functionality and cost less to maintain than a broad rewrite.
Validate usability as well as the trace
After a change, repeat the original journey on a representative mobile device. Check keyboard operation, focus, validation and loading feedback. A quick visual response is not a successful fix if the interaction stops being accessible or sends duplicate requests.
Compare the lab behaviour immediately, then monitor field results as fresh data becomes available. Keep release dates and other site changes in the record so a later improvement is not attributed to the wrong intervention.
ArAgile’s web development work can include this kind of focused performance investigation. For teams running tests, we can also review experimentation implementation alongside the underlying page. The deliverable should explain the slow interaction, the change and how its effect was checked.
Discuss a WordPress performance and interaction audit
Tell us about your existing setup, the process you want to improve and the constraints that matter.