SEO

INP (Interaction to Next Paint)

Q: What is INP (Interaction to Next Paint)?

INP measures how quickly a page responds to user interactions — clicks, taps and keyboard input. It is the successor to FID (First Input Delay) and has been an official Core Web Vital since March 2024. Thresholds: under 200ms ”good", 200–500ms ”needs improvement", over 500ms ”poor".

Q: What is the difference from FID?

INP measures all interactions, FID only the first. This is more realistic for the user experience — a page may respond quickly to the first click but slowly to later ones. INP shows the worst-case behaviour of the page.

Q: What typically delays INP?

Three causes: (1) blocking JavaScript tasks over 50ms, (2) large DOM re-renders on interaction, (3) third-party scripts that block the main thread. Optimisation: split JavaScript chunks, optimise rendering, audit third parties.

Q: Is INP harder to optimise than LCP?

Often yes — optimising INP requires deeper code knowledge. LCP can usually be improved fairly easily with image optimisation and CSS structure. INP requires JavaScript analysis, rendering optimisation and often framework-specific knowledge.

Also known as: INP, Interaction to Next Paint

Interaction to Next Paint (INP) has been the Core Web Vitals interactivity metric since March 2024, replacing FID (First Input Delay). INP measures the response time to all clicks, taps and keyboard events in a session and takes the worst percentile (often the 98th percentile). It is therefore stricter than FID, which only measured the first input event. Target: under 200 ms for ”Good", 200–500 ms for ”Needs improvement", over 500 ms for ”Poor".

What INP actually measures

Every click, tap or keyboard event triggers a measurement: from the moment of the input until the next visual update on screen. If the browser is blocked by heavy JS code, the visual update takes longer to appear — INP shows this lag. Important: INP does not only measure the first clicks (as FID did) but every interaction in a session — anyone who triggers a heavy filter event on page 3 after 10 seconds influences INP just as much as the first click.

Optimising INP

Break up long tasks — JS code that runs longer than 50 ms on the main thread blocks INP. Use scheduler.yield() or requestIdleCallback.
Split heavy JS bundles — code splitting with dynamic imports.
Isolate third-party scripts — tag managers, ads and chat widgets are frequent INP killers. Use web workers or async loading.
React/Vue optimisation — useMemo, useCallback, virtualised lists.
Event handler optimisation — debouncing/throttling on scroll, input and resize.
CSS hover effects using transform and opacity instead of layout-triggering properties.

INP diagnostic tools

Chrome DevTools performance panel — recordings with long tasks visualised.
web-vitals.js library — real-time INP measurement with element attribution.
CrUX dashboard — INP values per URL over time.
Lighthouse — synthetic INP score plus diagnostic notes.
WebPageTest — INP plus long task visualisation.

Example from practice

Example: A React shop had an INP of 380 ms (needs improvement). Audit: clicking the ”Change size" buttons triggered a 220 ms long task caused by un-memoised React re-renders of the entire product list. Optimisation: useMemo for the product list, a virtualised list instead of a fully rendered one, and the filter logic moved into a web worker. After 6 weeks: INP 140 ms (Good). Ranking-relevant: the domain has INP values in the sweet spot in the mobile-first index without anything else about performance being changed.

Frequently asked questions

What is INP (Interaction to Next Paint)?

INP measures how quickly a page responds to user interactions — clicks, taps and keyboard input. It is the successor to FID (First Input Delay) and has been an official Core Web Vital since March 2024. Thresholds: under 200ms ”good", 200–500ms ”needs improvement", over 500ms ”poor".

What is the difference from FID?

INP measures all interactions, FID only the first. This is more realistic for the user experience — a page may respond quickly to the first click but slowly to later ones. INP shows the worst-case behaviour of the page.

What typically delays INP?

Three causes: (1) blocking JavaScript tasks over 50ms, (2) large DOM re-renders on interaction, (3) third-party scripts that block the main thread. Optimisation: split JavaScript chunks, optimise rendering, audit third parties.

Is INP harder to optimise than LCP?

Often yes — optimising INP requires deeper code knowledge. LCP can usually be improved fairly easily with image optimisation and CSS structure. INP requires JavaScript analysis, rendering optimisation and often framework-specific knowledge.

Used in Rankmio for

INP audit in the SEO check

Go to the feature →

Last updated: 2026-06-17 · Browse all glossary entries