التفاعل حتى العرض التالي (INP)

Interaction to Next Paint (INP) measures how quickly the page visually responds to user input across the whole visit. It became a Core Web Vital, replacing First Input Delay.

FID only measured the first interaction's input delay. INP is broader: it considers all interactions and the full latency through event handling and rendering, not just the initial delay.

Each interaction's latency spans three parts: input delay (waiting for the main thread), processing time (event handlers), and presentation delay (rendering the next frame).

Across a visit, INP reports roughly the worst interaction latency (with an allowance for outliers on pages with many interactions), so it reflects the user's worst-case responsiveness.

• Good: 200ms or less
• Needs improvement: 200-500ms
• Poor: over 500ms

Long tasks block the main thread so input cannot be handled promptly. Breaking up long JavaScript tasks is the single biggest lever for improving INP.

Break long work into chunks and yield so the browser can handle input between them. scheduler.yield() or a setTimeout based yield helps.

Update the UI immediately for feedback, then run heavy work afterward. Patterns like requestAnimationFrame for visual updates and deferring analytics keep handlers short.

The presentation phase suffers from large DOM updates and expensive layout. Use content-visibility, virtualization, and minimal DOM changes to render the next frame faster.

Capture INP in the field with the web-vitals library, and use the DevTools Performance panel's interaction track to see input delay, processing, and presentation for each event.

• Break up long tasks and yield.
• Defer non-urgent work after paint.
• Trim event handler work.
• Reduce DOM size and rendering cost.

You learned INP measures whole-visit responsiveness across input delay, processing, and presentation, with a good threshold of 200ms. Improve it by breaking up long tasks, yielding to the main thread, deferring non-urgent work, and reducing rendering cost.