Measure and improve interaction responsiveness with INP Scanner

This guide explains INP and how to use INP Scanner by Milten to investigate slow interactions. INP replaced FID in Core Web Vitals in March 2024. A laboratory run covers the actions actually performed, rather than every visitor’s experience.

What is Interaction to Next Paint (INP)?

Interaction to Next Paint (INP) assesses responsiveness to clicks, taps and keyboard interactions during a page visit. An interaction’s latency includes input delay, event-handler execution and the delay before the next paint. Unlike FID, which measured only the first input delay, INP considers eligible interactions throughout the visit. It does not measure the full duration of a later asynchronous network response.

Key Features of INP:

• Aggregation: INP is not an average. It generally reflects the slowest interaction, with outliers excluded for visits containing many interactions.
• Thresholds: good at 200 ms or less; needs improvement above 200 ms and up to 500 ms; poor above 500 ms. For real-user assessment, use the 75th percentile, separating mobile and desktop visits.
• Included interactions: clicks, taps and keyboard input. Scrolling and hovering are not themselves measured as INP interactions.

Why is INP Important for You?

1. User Experience (UX)

Slow visual feedback can make a button feel unresponsive and lead to repeated clicks. Measure the actual interaction and its outcome. Statistics about page loading cannot be treated as a measured effect of INP on your site’s bounce rate.

2. SEO and Search Rankings

INP is part of Core Web Vitals, which Google’s ranking systems use. A good score does not guarantee a higher position, and a poor score does not establish a fixed ranking penalty. Assess responsiveness alongside content relevance and other aspects of page experience.

3. Speed as a Competitive Advantage

Prompt visual feedback helps users understand that an action was received. Compare the actions that matter to your audience, rather than assuming every millisecond has the same effect on every task.

How to use INP Scanner by Milten

INP Scanner helps investigate responsiveness in a controlled browser run. Check the report’s tested actions and limitations before generalizing its findings.

1. Check the tested interactions

Choose a representative flow and confirm which actions the run performed:

• Clicks on buttons and links.
• Keyboard input in relevant fields.
• Scrolling needed to reach an element; scrolling itself is not an INP interaction.

A controlled browser run is a reproducible scenario, not a measurement on every visitor’s device. Record the actual browser, device profile and test conditions. Add manual tests for important flows the run did not cover.

2. Interpret the timing data

INP measurement uses Event Timing data. PerformanceObserver can observe supported event entries; there is no general render entry type for this purpose. A metric library such as web-vitals handles interaction grouping and INP calculation.

• Distinguish input delay, handler execution and presentation delay.
• Investigate long JavaScript tasks on the main thread.
• Treat animation smoothness as a related but separate diagnostic question.

3. Investigate the findings

Use the evidence actually present in the report:

• Identify the recorded interactions and their target elements.
• Investigate a slow action, such as an illustrative “Buy” button taking 600 ms; this number is an example, not a customer measurement.
• Verify suspected causes in a browser performance trace and test a focused code change.

Limits of an automated run

• Check the current service conditions and available report fields.
• A browser test does not establish that physical user devices were tested.
• Untested actions and unavailable data remain unverified; supplement the run with field data where available.

Common causes of slow interactions

1. Long Event Handlers

Example:

button.addEventListener('click', () => {
	// Synchronous processing of 10,000 data rows
	const result = heavyCalculation(data)
	updateUI(result)
})

Problem: synchronous heavyCalculation work keeps the main thread busy and can delay the next paint. Solution: reduce or split that work, or move suitable computation to a Web Worker. A single setTimeout only schedules the same heavy task later; it does not move it off the main thread.

2. Render-Blocking CSS/JS

Example:

<link rel="stylesheet" href="large-styles.css" />
<script src="analytics.js" defer></script>

Problem: a blocking stylesheet and expensive script execution can delay rendering or input handling. defer changes script scheduling but does not make execution free. The example stylesheet applies to the screen; using only media="print" would leave screen styles unapplied. Possible improvements:

• Inline only genuinely critical CSS after measuring the trade-off.
• Remove unused styles only after checking dynamic classes and interface states; tools such as PurgeCSS need the right configuration.
• Defer non-critical scripts and reduce their execution cost.

3. Slow Animations

Example:

@keyframes fade {
	from {
		opacity: 0;
		transform: translateX(-100px);
	}
	to {
		opacity: 1;
		transform: translateX(0);
	}
}

Problem: While opacity and transform animations are usually fast, they can stutter when applied to many elements.
Solution:

• Simplify the animation and reduce simultaneous animated elements.
• Consider will-change: transform only for elements that need it, shortly before the change. Measure the result: it is a hint, not a guarantee of GPU acceleration, and overuse consumes resources.

4. Repeated forced layout (layout thrashing)

Example:

for (let i = 0; i < 100; i++) {
	element.style.height = `${i}px`
	console.log(element.offsetHeight) // Forces layout recalculation
}

Problem: alternating style writes and layout-dependent reads such as offsetHeight can force repeated layout calculations. Layout is not the same operation as painting. Solution:

• Group layout reads before writes wherever possible.
• Schedule visual changes with requestAnimationFrame when appropriate, but do not repeat the same read/write loop inside it and expect the problem to disappear.

How to Improve INP: 5 Practical Tips

1. Optimize Event Handlers

• Split long tasks and yield to the browser between chunks, using an appropriate task-scheduling mechanism such as setTimeout.
• queueMicrotask does not yield an opportunity to paint; a chain of microtasks can keep the page blocked.
• Keep the immediate event-handler work small and show prompt feedback.

2. Reduce JavaScript Bundle Size

• Remove unused libraries (e.g., using Webpack Bundle Analyzer).
• Apply code splitting to load modules dynamically.

3. Use Debouncing and Throttling

For search input or frequent events, debounce or throttle expensive work where the task permits. The example assumes debounce is defined or imported. Keep the input’s own visual feedback immediate; the 300 ms delay is an illustrative scheduling choice, not an INP target:

const debouncedSearch = debounce((query) => {
	fetchResults(query)
}, 300)

4. Optimize Rendering

• Reduce unnecessary DOM complexity.
• Profile style and layout costs instead of assuming selector complexity is always the cause.
• Consider content-visibility: auto for offscreen sections and verify layout, focus and accessibility behavior.

5. Test on Low-End Devices

Test representative low-end devices when possible. Browser developer tools can emulate slower CPUs and networks, for example a 4× CPU slowdown and a constrained mobile connection. These are illustrative lab settings, not a claim that this service uses a fixed 3G profile or tests physical devices.

Verify the result

Repeat the same interaction after publishing the fix, using comparable conditions. Confirm both response time and task correctness: a faster cart must still contain the right item.

Use INP Scanner by Milten as part of that investigation:

• Record the actions tested and any missing evidence.
• Compare a reproducible before-and-after flow.
• Use real-user measurements to assess actual visits, rather than treating a good laboratory result as proof for all users.

Choose one important slow interaction, identify a plausible cause and test a limited correction. Keep successful, failed and unperformed checks distinct.

For metric details, see the INP specification and measurement guide and INP optimization guide.