Poor INP in field data (p75 > 500 ms)
cwv_inp_poorShort answer
Interaction to Next Paint measures how long the page takes to visually respond after a user clicks, taps or presses a key, across the whole visit. Here the 75th percentile is above 500 ms, Google's "poor" threshold (good is ≤ 200 ms). The page responds to clicks after more than 500 ms; users think the interface has frozen. The cause is JavaScript keeping the main thread busy: long tasks, heavy event handlers, third-party scripts and layout thrashing. Break up long tasks and defer what is not needed.
Why it matters
INP is a Core Web Vital since March 2024 and is part of the page-experience signal. Unlike LCP it covers the whole session, so a page that loads fast but freezes when the user opens the menu or filters a list still fails. Poor INP is strongly correlated with abandoned forms and carts.
How Glimana detects it
Glimana reads inp_p75 from CrUX field data for the origin or URL and fires when it is above 500 ms. The evidence shows the p75; the Speed page shows the distribution and the Lighthouse "Total Blocking Time" and long-task audits that usually point to the culprit.
How to fix it
- Find the slow interactions. Chrome DevTools › Performance, record while clicking around; look for long tasks (red corners) right after an input. The Web Vitals extension logs INP per interaction.
- Shrink the handler. Do only what is needed to update the UI synchronously; move the rest (analytics, fetches, recalculations) to
setTimeout,requestIdleCallbackorscheduler.yield(). - Yield to the main thread. Split loops over large lists into chunks; let the browser paint between them.
- Defer third parties. Chat widgets, heat-map recorders and tag managers often attach heavy listeners to every click. Load them after interaction or remove them.
- Avoid forced layout. Reading layout properties (
offsetHeight) inside a loop that also writes styles forces repeated layouts.
Use the cache plugin's "delay JavaScript until interaction" option carefully: it improves load metrics but can make the first interaction slow (everything executes at once). Prefer removing unused plugins and heavy sliders. Check that jQuery-based plugins are not attaching handlers to document for every element.
Apps are the usual cause: each one listens to clicks for upsells, reviews, wishlists. Audit App embeds, remove the ones you do not use, and keep variant-selection JavaScript lean (avoid re-rendering the whole product form on each change).
Use scheduler.yield() / await points inside long handlers, memoise expensive renders (React useMemo, virtualised lists), debounce input handlers, and move heavy computation to a Web Worker. Measure with the web-vitals library's onINP with attribution to see which element and script are responsible.
How the fix is verified
Verified manually, because field data lags by about 28 days. Mark the task done once your lab tests show the interactions responding under 200 ms; the rule stops firing when the CrUX p75 drops below 500 ms.