High INP score
The page loaded fast. Then somebody clicked.
INP — Interaction to Next Paint — is Google's measurement of the moment users judge hardest: the gap between tapping something and the page visibly responding. A failing INP means your site feels broken to real fingers even if every loading metric glows green. It's the vital that measures feel.
Same-day diagnosis. Flat quote before any fix.
What’s actually happening
Where LCP measures arrival and CLS measures stability, INP measures conversation: every tap, click, and keypress on your page, timed from input to the next visual frame. Google reports the slowest of these interactions (roughly the worst-case), because users remember the tap that did nothing. Under 200 milliseconds feels instant; past 500 feels dead — and 'feels dead' is when people tap again, harder, or leave.
The physics is JavaScript's single main thread. When a long task is running — a bloated event handler, a third-party script, an analytics beacon, a builder's runtime — the thread can't paint your button's response until it finishes. High INP is nearly always long tasks blocking the thread at the moment of interaction, which is why the repair is profiling work: find the tasks, break them up, defer what doesn't belong at tap time, delete what doesn't belong at all.
The usual causes, ranked
After twenty-seven years of these calls, the odds are well mapped. Start at the top.
Heavy event handlers
Click handlers doing real work — recalculating, fetching, rerendering — synchronously before the paint. The interaction pays for everything attached to it.
Third-party scripts hogging the thread
Tag managers, chat widgets, heatmaps, and pixels running long tasks that happen to collide with taps. Your code is innocent; your page still fails.
Builder and framework runtimes
Page-builder hydration and oversized bundles keeping the thread busy long after load 'finished' — the site looks ready before it can actually respond.
Layout thrash on interaction
Handlers that force style recalculation across huge DOMs — menus and accordions that make the browser re-lay-out the world before painting.
What you can safely try first
Nothing below can make things worse — that’s the selection criterion. Anything riskier belongs in professional hands, on a backup.
- 1
Read the field data, not just the lab
PageSpeed Insights' top section is real-user data — that's what Google judges. Note whether INP fails on mobile, desktop, or both; mobile-only failure implicates cheaper hardware choking on the same scripts.
- 2
Feel it yourself on a mid-range phone
Tap the menu, the filters, the add-to-cart. The interactions that feel mushy are the long tasks; you can diagnose the vibe before anyone profiles a millisecond.
- 3
Inventory the third-party scripts
List every widget, pixel, and tag. Each is a suspect renting time on your main thread. You don't need to remove them yet — knowing the roster is the start.
Stop and call when…
- The fix requires profiling long tasks and refactoring handlers — performance-engineering work, not a plugin install
- Third parties you're contractually stuck with are the cause — mitigation strategy territory
- INP fails only at scale or only on mobile — the reproduction itself takes tooling
From there it’s our job: same-day look, flat quote, and the $679 flat repair covers most cases of exactly this.
Site Speed Tune-Up — buy it now, skip the hunt.
Images, scripts, and caching tuned — measurably faster inside 48 hours of starting.
Covers one site: image optimization, script cleanup, caching configuration, and a before/after PageSpeed report. Platform-level rebuilds quoted separately if the site needs more.
Questions we hear a lot.
My LCP is great — why does INP fail?
Because they measure different acts. LCP times the page's arrival; INP times its responsiveness once you're there. A page can paint fast and then sit with a jammed main thread for seconds — beautifully delivered, functionally deaf. That split profile is common on builder-heavy WordPress and script-heavy stores.
Does a failing INP actually hurt rankings and sales?
Both, differently. Core Web Vitals influence rankings at the margin — real, not dramatic. The sales effect is less subtle: dead-feeling taps are where users double-submit forms, rage-click, and abandon carts. You fix INP for the customers first; Google's approval is the bonus.
What does the $679 speed tune-up cover for INP?
Profiling real interactions to name the long tasks, breaking up or deferring the offenders, right-sizing third-party loading, and re-measuring against the same field-and-lab baseline we started from. Before-and-after numbers, in writing — the same discipline as every speed job we take.
Related symptoms & help
Errors travel in packs. If this one visited, check its friends.
Make every tap answer instantly. Measured.
Send the symptom, get a same-day look and a flat quote from the developer who's fixed this exact thing more times than either of us can count.