A website can load quickly and still feel slow when a menu, filter, form or button takes too long to respond. Interaction to Next Paint, usually shortened to INP, measures that responsiveness across clicks, taps and keyboard interactions.
Quick answer: start with real-user INP data, identify the slow interaction, reproduce it under realistic conditions, then reduce the JavaScript and rendering work blocking the next visual update. Do not install another optimisation plugin until you know what is slow.
INP is one of the three Core Web Vitals discussed in the Core Web Vitals guide. This article focuses on a practical diagnosis and repair workflow that applies across content management systems and web frameworks, with WordPress-specific checks where relevant.
What counts as a good INP?
Google’s web.dev guidance classifies an INP of 200 milliseconds or less as good at the 75th percentile of page visits, measured separately for mobile and desktop. More than 200 milliseconds and up to 500 milliseconds needs improvement; above 500 milliseconds is poor.
INP observes the delay from the start of an interaction until the browser can present the next frame. That time can include input delay, event-handler processing and presentation delay. It is not simply a page-load measurement.
INP | Assessment | Practical meaning |
|---|---|---|
200 ms or less | Good | Most users receive prompt visual feedback |
Over 200 to 500 ms | Needs improvement | Some interactions feel noticeably delayed |
Over 500 ms | Poor | The interface can appear unresponsive |
Measure field data before making changes
Begin with the Core Web Vitals report in Google Search Console or PageSpeed Insights. Field data represents real Chrome visits, but lower-traffic pages may not have enough samples. When field data is unavailable, laboratory testing can still reveal likely causes, but it cannot prove the real-user percentile.
Group affected URLs by template. If many blog posts fail together, investigate shared theme code, menus, consent tools, analytics, adverts or page-builder components before editing an individual article.
Find the interaction that is actually slow
Test common user journeys on a mid-range phone or using CPU throttling in browser developer tools. Interact during page load as well as afterwards. Record which control is slow and whether the delay occurs consistently.
- Open and close the mobile navigation.
- Accept or reject the cookie banner.
- Use search, filters, accordions and tabs.
- Type into forms and trigger validation.
- Click sliders, carousels and load-more controls.
A performance trace can show whether the delay comes before event handling, inside a long JavaScript task or while the browser recalculates layout and paints.
Common causes of poor INP
Too much JavaScript on the main thread
Themes, block libraries, analytics, chat widgets, consent systems and marketing scripts may all add work. A script can be small in download size but expensive to parse or execute.
Long event handlers
A menu or filter may perform too much synchronous work after a click. Third-party listeners attached to the same event can also delay the next frame.
A very large document structure
Deeply nested page-builder containers and repeated decorative blocks increase the amount of work required for style calculation and rendering. This can increase presentation delay after an interaction.
Work competing during page load
If visitors interact while scripts are still executing, queued main-thread work can delay the event. This is why testing only after the page becomes idle can miss real problems.
A safe improvement process
Create a staging copy and record the baseline
Back up the site and use a staging environment for CMS, theme, extension and code changes. Record the affected URLs, field INP range, slow control and a repeatable laboratory test.
Remove functionality that is not earning its cost
Audit extensions, plugins and external scripts, but do not deactivate production features blindly. Test one change at a time. Remove duplicated tracking, unused blocks and abandoned widgets first.
Load non-essential scripts later
Defer or delay scripts that are not required for the initial interface, provided doing so does not break consent, accessibility or essential behaviour. Check each user journey after changing optimisation settings.
Break up long JavaScript tasks
Custom code should do the minimum synchronous work required to show feedback, then yield before continuing non-urgent processing. Developers can split large tasks and avoid repeated expensive calculations inside event handlers.
Reduce avoidable DOM complexity
Simplify deeply nested containers and repeated hidden content. Build long pages from meaningful sections rather than layers of layout wrappers. This can also make editing and accessibility testing easier.
Give immediate visual feedback
When an action genuinely needs time, update the interface immediately with a loading state or pressed state, then complete the heavier operation. The feedback itself must not be blocked by the same long task.
Treat caching as one part of performance
Page caching and a CDN can improve delivery and reduce server work, as explained in the website speed optimisation guide. They do not automatically fix JavaScript that blocks a user interaction after the page arrives.
Retest and monitor field data
Repeat the same laboratory interaction after every meaningful change. Deploy the smallest verified set of fixes, then monitor field data over the following weeks. Search Console’s validation process and Chrome field datasets need time to collect new visits.
WordPress-specific checks
On a WordPress site, use a staging copy to isolate theme, plugin and page-builder costs without disrupting visitors. Test one change at a time so you can identify the component responsible for the slow interaction.
- Temporarily disable or replace one suspected plugin at a time on staging.
- Check page-builder sections for deeply nested containers and hidden widgets.
- Test consent banners, forms, sliders, search and mobile navigation carefully.
- Avoid stacking optimisation plugins that modify the same scripts or caching behaviour.
If removing a plugin improves the trace, look for a lighter alternative or load it only on pages that need it. A plugin name alone is not proof of the cause; confirm the result by repeating the same interaction under the same test conditions.
Avoid these shortcuts
- Do not optimise solely for a single desktop Lighthouse run.
- Do not combine multiple performance tools or plugins with overlapping features without a test plan.
- Do not delay essential navigation or accessibility scripts just to improve a score.
- Do not assume the slowest laboratory task is the interaction real visitors experience.
- Do not change hosting when the trace shows client-side interaction work is the bottleneck.
Frequently Asked Questions
Here are some common questions about improving Interaction to Next Paint.
What is a good INP score?
An INP of 200 milliseconds or less at the 75th percentile is considered good. More than 200 milliseconds and up to 500 milliseconds needs improvement, while more than 500 milliseconds is poor.
Can caching fix poor INP?
Caching can improve delivery and reduce server work, but it does not automatically fix long JavaScript tasks, expensive event handlers or rendering work that delays visual feedback after an interaction.
Why does PageSpeed Insights sometimes show no INP data?
Field INP requires enough real Chrome visits and measured interactions. A new or low-traffic page may not have sufficient field data, so laboratory tests can help diagnose likely problems while more data accumulates.
Which website elements commonly cause slow interactions?
Mobile menus, cookie banners, filters, forms, interactive widgets, analytics and third-party marketing scripts are useful places to test. The actual cause should be confirmed with a repeatable interaction and performance trace.
Final Thoughts
A good INP project connects measurement to a real control that users touch. Find that control, reduce the work blocking its next frame and confirm the improvement in both repeatable testing and field data. For the wider technical context, continue with the technical SEO guide.
Primary references: web.dev: Interaction to Next Paint, web.dev: Optimise INP and Google Search Central: Core Web Vitals.
