Interaction to Next Paint is the Core Web Vital most WordPress sites are least prepared for, because it measures something a speed score barely shows: how quickly the page reacts when someone taps, clicks or types. Below I explain what INP measures in plain terms, how to find the interactions that are slow, and how to fix Interaction to Next Paint on a typical WordPress or WooCommerce site without breaking your tracking or your forms.
What INP measures, in plain English
When a visitor taps a menu button, the browser has to run whatever code is attached to that tap and then draw the result on screen. INP measures how long that takes, from the tap to the next visual update. It looks at the interactions across the whole visit and reports one of the slowest, so a single sluggish menu or “add to cart” button can drag the whole page down.
Google replaced First Input Delay with INP as a Core Web Vital in March 2024. FID only measured the delay before the first interaction started being handled, which most sites passed easily. INP is stricter, and plenty of sites that looked fine under FID now fail.
The thresholds: 200 milliseconds or less is good, 200 to 500 milliseconds needs improvement, and over 500 milliseconds is poor. Like the other vitals, it’s judged at the 75th percentile of real visits.
To a visitor, poor INP feels like a sticky site. The menu opens a beat late. A button does nothing for a moment, so they tap it twice. A filter freezes the page. People rarely describe it as slowness, but they feel it, and some of them leave.
Why INP is hard to see in a speed test
A lab test like the one in PageSpeed Insights loads the page but doesn’t click anything, so it can’t measure INP directly. The closest lab signal is Total Blocking Time, which shows how long the main thread was busy during loading. High TBT usually means poor INP, but a page can have fine TBT and still have one slow interaction later on.
To find real problems, use these in order:
- Search Console’s Core Web Vitals report shows whether INP is failing and on which groups of pages.
- PageSpeed Insights field data shows the real INP for a specific URL or the whole site, if you have enough Chrome traffic.
- The Chrome DevTools Performance panel shows live INP as you click around your own site. Turn on CPU throttling to simulate a mid-range phone, then tap the menu, the accordions, the filters and the add-to-cart buttons. The panel tells you which interaction was slowest.
The three parts of a slow interaction
Every interaction breaks into three stages, and the fix depends on which one is long.
- Input delay: the browser is busy with something else when the tap happens, usually a script that is still loading or running. Third-party scripts are the usual cause.
- Processing time: the code attached to the tap takes too long. Think of a mega menu that rebuilds itself, or a product filter that recalculates everything.
- Presentation delay: the code is done, but drawing the new screen is slow because the page has a huge number of elements or heavy CSS effects.
How to fix Interaction to Next Paint on WordPress
Cut and delay third-party scripts
Chat widgets, heatmaps, A/B testing tools, social embeds and multiple ad pixels all compete for the main thread. Remove anything nobody uses. For the rest, load chat widgets only when someone clicks a chat button, and delay non-essential scripts until the visitor interacts. Be careful with tracking: conversion tags shouldn’t be delayed in a way that loses conversions. I test every change in GA4 DebugView and Tag Assistant before it goes live, and if your tracking setup is messy, it’s worth rebuilding it cleanly rather than stacking delays on top.
Reduce the size of the page
A page with thousands of elements takes longer to update after every interaction. Page builders often produce deep nesting, and many sites duplicate whole sections for desktop and mobile, hiding one with CSS. Both copies still exist in the page. Converting old Elementor sections to containers and removing duplicate sections often helps INP more than any plugin. This is a big part of the speed optimization work I do on Elementor sites.
Simplify heavy interactive elements
- Mega menus with dozens of links, icons and images on every page.
- Product filters that reload a whole grid on every checkbox.
- WooCommerce variation swatches carrying large amounts of variation data.
- Sliders and carousels that run timers and animations constantly.
- Popups and cookie banners that run large scripts on the first interaction.
Each one can usually be replaced with a lighter version or configured to do less.
Ask your developer for code-level fixes
For custom code, the fixes are well known. Break long tasks into smaller pieces so the browser can respond in between. Give instant visual feedback, such as a pressed button or a loading state, before doing the heavy work. Avoid reading and writing layout repeatedly in loops. Debounce handlers that run on scroll and typing. These are developer tasks, but you should know they exist so you can ask for them.
Be careful with “delay JavaScript” settings
Optimization plugins can delay scripts until the first interaction. That helps loading metrics, but if a large bundle then runs on the first tap, that tap becomes slow and INP gets worse. Test the first interaction specifically after turning this on.
Quick checklist
- Check INP in Search Console and PageSpeed Insights field data.
- Reproduce slow interactions in Chrome DevTools with CPU throttling.
- List every third-party script and remove the ones you don’t need.
- Load chat and heavy widgets on click instead of on page load.
- Reduce DOM size, especially duplicated desktop and mobile sections.
- Simplify mega menus, filters and swatches.
- Retest the first interaction after any “delay JavaScript” change.
Worth reading next: how to fix Largest Contentful Paint on a WordPress site and how to fix Cumulative Layout Shift on a WordPress website.
Questions I get about INP
What is a good INP score?
200 milliseconds or less at the 75th percentile of real visits. Over 500 milliseconds is poor.
Why does PageSpeed Insights not show INP in the lab results?
Lab tests do not interact with the page. INP only appears in field data from real Chrome users. Use Total Blocking Time and your own testing in DevTools as stand-ins.
Can a caching plugin fix INP?
Not much. Caching speeds up delivery of the page. INP is about the work the browser does after the page has loaded. The fixes are fewer scripts, smaller pages and lighter interactive features.
Does INP affect my Google rankings?
It’s part of Core Web Vitals, which Google uses as one of many page experience signals. Relevance matters far more, but a laggy site also costs you leads directly, which is reason enough to fix it.
If your site feels slow to respond and you can’t tell why, send me the URL for a free website review. I’ll find the slow interactions and tell you what is causing them.
