Free — no signup required

INP (Interaction to Next Paint)

2 min read

Measuring Responsiveness

When a user clicks a button, taps a menu, or presses a key, they expect immediate visual feedback. The human perception threshold for "instant" is roughly 100ms. Beyond 200ms, interactions start to feel sluggish. Beyond 500ms, users assume something is broken.

Interaction to Next Paint (INP) measures the time from when a user interacts with the page to when the browser paints the next frame showing the visual result of that interaction. It replaced the older First Input Delay (FID) metric in March 2024. The key difference: FID only measured the delay before the browser started processing the first interaction. INP measures the full round-trip — input to visual response — for all interactions throughout the page's lifetime, reporting the worst one (with some outlier tolerance).

Thresholds:
- ✅ Good: 200 milliseconds or less
- ⚠️ Needs Improvement: 200ms – 500ms
- ❌ Poor: More than 500 milliseconds

Common causes of poor INP:
- Long Tasks: JavaScript tasks that run for more than 50ms on the main thread block the browser from processing input. A 300ms synchronous data transformation triggered by a click will produce a 300ms+ INP.
- Excessive DOM size: Browsers take longer to calculate layout and paint when the DOM has tens of thousands of nodes.
- Synchronous third-party scripts: Analytics, chat widgets, and A/B testing scripts that execute on the main thread compete with user interactions.

The primary fix is breaking up long tasks using setTimeout, scheduler.yield(), or moving work to Web Workers so the main thread remains available to respond to input.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free