Many WordPress sites now pass Largest Contentful Paint and Cumulative Layout Shift, then sit in the red because of a third metric: Interaction to Next Paint. INP is harder to fix because it is not about how fast the page loads, but how fast it reacts once someone starts using it. Here is what it measures, how to diagnose it, and the fixes we apply on WordPress sites.
What INP measures
Interaction to Next Paint measures the delay between a user interaction (a click, a tap, or a key press) and the next time the browser paints a visual response. Scrolling and hovering do not count.
The browser observes every qualifying interaction during the visit, not just the first one. The page’s INP value is close to the slowest of those interactions. On pages with many interactions, a small number of the very worst outliers are ignored, so one freak delay does not define the score. Google then reports the 75th percentile of those values across real visits, which means three out of four visits need to be fast for a URL to pass.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID only measured the input delay of the first interaction, which most sites passed easily. INP is much stricter.
| INP at the 75th percentile | Rating |
|---|---|
| 200 ms or less | Good |
| Over 200 ms, up to 500 ms | Needs improvement |
| Over 500 ms | Poor |
The three parts of an interaction
Every slow interaction can be broken into three phases, and knowing which one dominates tells you what to fix:
- Input delay. The browser is busy with other work (often a script that is still running) and cannot start handling the event yet.
- Processing duration. Your event handlers run. Heavy click handlers, analytics callbacks, and framework updates all land here.
- Presentation delay. The browser recalculates styles, lays out the page, and paints. A huge DOM or expensive CSS makes this phase slow.
Field data vs lab data
INP depends on real users, real devices, and real behavior, so field data is what decides whether you pass.
| Tool | Type | What it is good for |
|---|---|---|
| Chrome UX Report (CrUX) | Field | The 28-day dataset Google uses for Core Web Vitals |
| Search Console, Core Web Vitals report | Field | Groups of similar URLs that pass or fail, on mobile and desktop |
| PageSpeed Insights | Field and lab | CrUX field data at the top, a Lighthouse lab run below |
| Chrome DevTools Performance panel | Lab | Recording an interaction and seeing exactly which tasks ran |
| web-vitals JavaScript library | Field (your own) | Collecting INP from your real visitors, with attribution |
Two things trip people up. First, a Lighthouse score in PageSpeed Insights does not measure INP directly, because Lighthouse does not click anything. Total Blocking Time is its rough lab proxy. Second, Search Console updates slowly. After a fix, it takes about four weeks of new data before CrUX and Search Console fully reflect it.
The most useful setup is your own field data. The attribution build of the web-vitals library tells you which element was interacted with, which phase was slowest, and which scripts ran during the slow frame. Send that to your analytics and you will know exactly which interaction to reproduce in DevTools.
Why WordPress sites fail INP
WordPress itself is not the problem. The problem is what typically gets layered on top of it:
- Heavy page builders. Builders that wrap every element in several nested containers create very large DOMs and ship a lot of JavaScript for features each page does not use.
- Third-party scripts. Ad networks, A/B testing tools, heatmaps, and social embeds all compete for the main thread.
- Sliders and carousels. Many run timers and animations constantly, and initialize on every page even when the slider is below the fold.
- Chat widgets. These are often large bundles that load early and attach their own listeners.
- Analytics and tag managers. A tag manager container with years of accumulated tags can run a lot of code on every click.
- jQuery-heavy plugins. Older plugins frequently attach broad event handlers and do synchronous DOM work on interaction.
- Large DOM size. Mega menus, long product grids, and hidden mobile duplicates of desktop content all make style and layout work more expensive.
A workflow for fixing INP
This is the order we work in on client sites:
- Confirm the problem in field data. Check Search Console and PageSpeed Insights to see which URL groups fail, and whether it is mobile, desktop, or both. Mobile is usually worse.
- Find the slow interactions. Use web-vitals attribution data, or test the obvious candidates by hand: menu toggles, add-to-cart buttons, filters, accordions, form fields, and cookie banners.
- Reproduce in DevTools. Open the Performance panel, enable CPU throttling to approximate a mid-range phone, record, and perform the interaction. Look for long tasks (over 50 ms) around the event.
- Identify the culprit script. The flame chart shows which file and function ran. Map it back to a plugin, theme, or third-party tag.
- Fix the biggest task first. Remove, defer, replace, or break up the work, then measure again in the lab.
- Ship and watch the field. Monitor your own INP data for a few days, then confirm the trend in CrUX over the following weeks.
Common causes and fixes
| Cause | What you see in DevTools | Fix |
|---|---|---|
| Page builder bloat | Long style and layout work after each click | Simplify templates, reduce nesting, or move key templates to a lighter theme |
| Third-party tags | Long tasks from external domains | Remove unused tags, load the rest after interaction or on specific pages only |
| Chat widget | Large script evaluation near the interaction | Load the widget on click of a placeholder button |
| Slider or carousel | Recurring timers and animation work | Replace with a static hero, or initialize only when visible |
| jQuery plugin handlers | Long event handler in the processing phase | Replace the plugin or narrow its handlers to the elements that need them |
| Large DOM | Long presentation delay | Cut hidden duplicate markup, paginate long lists, use content-visibility: auto |
| Expensive custom code | One long task inside your own handler | Update the UI first, then yield before the remaining work |
Breaking up long tasks
When code must run on interaction, give the browser a chance to paint between chunks of work. scheduler.yield() is supported in current Chromium-based browsers. A setTimeout fallback covers the rest:
function yieldToMain() {
if (globalThis.scheduler?.yield) {
return scheduler.yield();
}
return new Promise((resolve) => setTimeout(resolve, 0));
}
button.addEventListener('click', async () => {
showLoadingState(); // visible feedback first
await yieldToMain(); // let the browser paint
runFilterLogic(); // heavier work afterward
await yieldToMain();
sendAnalyticsEvent(); // non-urgent work last
});The pattern is simple: do the minimum needed for visual feedback, yield, then do everything else. Analytics calls in particular almost never need to block the next paint.
WordPress-specific tips
- Delay JavaScript execution carefully. Optimization plugins can delay scripts until the first user interaction. That helps loading metrics, but every delayed script then runs at once on that first tap, which can produce a very slow interaction. Delay third-party and non-critical scripts, and exclude scripts needed for menus, carts, and forms.
- Remove unused plugins. Check which plugins enqueue scripts on pages where they do nothing, then remove them or load them only where they are needed.
- Choose a lighter theme. A lean block theme or a well-built lightweight theme usually ships far less JavaScript and markup than a multipurpose theme with every feature enabled.
- Defer third parties. Load chat, reviews, and video embeds through a facade (a static placeholder that loads the real thing on click).
- Reduce DOM size. Avoid separate desktop and mobile versions of the same section, simplify mega menus, and limit how many products or posts load at once.
- Audit the tag manager. Remove tags for tools you no longer use, and stop firing tags on every click when they only need page views.
These fixes do not require a redesign. On one agency-built WordPress site, we took the PageSpeed score from 42 to 100 without changing the design, and on another project we moved 30 pages out of the red in the Search Console Core Web Vitals report. The work was mostly removing, deferring, and restructuring what was already there.
Need a hand?
If your Search Console report shows INP issues and you are not sure which plugin or script is responsible, our Core Web Vitals service covers diagnosis, fixes, and field monitoring for WordPress sites. You can also hire us directly to look at your site.
