The short version
Interaction to Next Paint measures the delay between someone tapping and the page visibly responding, across the whole visit, reported at close to the worst interaction rather than the average. On a contractor site the taps that matter are the call button and the quote form, and those are exactly the elements page builders wrap in the most JavaScript. The typical failure is that a chat widget, a heat-map script and a form-validation bundle all wake up on first interaction - so the very first tap is the slowest one the visitor will ever make, and it is the tap that decides whether they call you. Fixing it is usually three changes, none of which require rebuilding the site.
What INP actually measures
Interaction to Next Paint measures how long the page takes to visually respond when someone interacts with it - a tap, a click, a key press. Not how long the resulting action takes to finish, but how long before anything on screen changes to acknowledge it happened.
Two details make it harsher than the metric it replaced. It watches the whole visit rather than the first interaction, so a page that is snappy on load and sluggish once everything has booted still fails. And it reports near the worst interaction rather than the average, which means one badly blocked tap in a session is the score - you cannot offset it with nine fast ones.
Why contractor sites fail it specifically
On a contractor site there are two interactions that matter and they are the two that carry the money: the call button and the quote form. Everything else is browsing. That concentration is unusual - a news site has hundreds of meaningful interactions spread across a visit, a contractor site has two - and it means the metric and the business outcome point at exactly the same elements.
Page builders then do the worst possible thing with those elements. The call button is often not a link but a scripted component. The form is a plugin with its own validation bundle. Both are wrapped in the builder's own event handling, which sits on top of a JavaScript payload assembled to support every feature the builder offers rather than the four the site uses.
The first-interaction cliff
The specific pattern worth recognising is that the first tap is usually the slowest. A great deal of third-party code is configured to initialise lazily - on first scroll, first click, first touch - because that scores well on load metrics. The chat widget, the heat-map recorder, the analytics bundle and the form validator all queue behind the same signal, and then all wake at once when the visitor does the first thing they came to do.
To the person tapping, the button is broken. They tap again. Now there are two queued events behind a busy main thread, and the second tap frequently makes it worse. This is why the failure is so often described as 'it sometimes doesn't work' rather than 'it's slow' - intermittent unresponsiveness is what a blocked main thread feels like from the outside.
The fix list, in order of impact
Defer the chat widget until first scroll or five seconds, whichever comes first. On most contractor sites this alone moves INP more than everything else combined, because chat is typically the heaviest third party present and it is almost never the reason anyone visited.
Replace the form plugin with a native form posting to a server function. A plugin form loads a validation library, a styling layer and often an analytics hook to do what the browser does natively; the native version is faster, degrades gracefully with JavaScript off, and removes an entire dependency from the path.
Then drop duplicate analytics. Running two tag managers is far more common than people expect - one installed by a previous agency, one by the current one, neither aware of the other - and it doubles the cost of every event on the page.
Where to look at your own numbers
Search Console's Core Web Vitals report is the one that counts, because it reports field data from real visitors on real devices. A lab tool running on a fast connection with a desktop CPU will tell you the page is fine while your actual visitors on a three-year-old Android in a basement are the ones producing the score.
The distinction matters most for exactly this metric. Lab tools simulate a single interaction under controlled conditions; INP is about the worst interaction a real person had after all the third-party code finished loading, which is a state a synthetic test rarely reaches.
What the fix is actually worth
The honest framing is that INP is a small ranking factor and a large conversion factor. Nobody has ever moved from position eleven to position three by fixing it. What changes is the proportion of people who tap the call button and reach a phone call rather than a stalled page - and on a site where two interactions carry all the revenue, a few percent of taps recovered is worth considerably more than the ranking movement would have been.
That is also the argument for doing it even if you are ranking fine. The metric is a proxy; the thing being measured is whether your customers can use the buttons.
The part that is not a scoring metric at all
Strip the scores out and there is still a reason to care. A page that responds late to a tap feels broken to the person using it, and people do not diagnose that, they just leave and try someone else.
That reaction is strongest on exactly the traffic you most want. Someone searching on a phone with a problem in their house has no patience budget to spend on a menu that takes half a second to open. They are not comparing your site to a benchmark, they are comparing it to the next result, and the next result opens instantly.
So we treat responsiveness as a conversion item that happens to also be a ranking item. That ordering matters, because it changes what you fix first: the tap targets on the pages people actually land on, rather than the worst score on a report of pages nobody visits.
Check it on your own site
Open Search Console, not a lab tool
Core Web Vitals, mobile, and look at INP specifically. This is field data from real visits, which is the only source that reflects what your customers on older phones actually experienced. A lab score of ninety-eight and a failing field INP is a normal combination.
Count your third-party scripts
View source or check the network tab and list every external domain being loaded. Chat, heat maps, tag managers, review widgets, font services, booking embeds. Most contractor sites carry between six and twelve, and can usually justify three.
Look specifically for two tag managers
Search the page source for gtm.js and for any second analytics loader. A leftover container from a previous agency is the single most common piece of dead weight we find, and removing it costs nothing because nobody is reading its data.
Defer the heaviest third party and re-measure in a month
Field data lags, so the report will not move immediately. Make the one change, wait twenty-eight days for the rolling window to refresh, and compare - changing three things at once means learning nothing about which one mattered.