INP Explained — Interaction to Next Paint Deep Dive

Understanding Interaction to Next Paint (INP)

INP became a Core Web Vital in March 2024, replacing First Input Delay (FID). While FID only measured the delay of the first interaction, INP measures the latency of all interactions throughout the page lifecycle and reports the worst one (with outlier trimming).

How INP Is Measured

An "interaction" in INP terms includes:

• Clicks (mousedown → mouseup → click)
• Taps (touchstart → touchend → click)
• Key presses (keydown → keyup)

Scrolling and hovering are not interactions for INP purposes.

For each interaction, INP measures the total time from user input to the next frame being painted:

INP = Input Delay + Processing Time + Presentation Delay

• Input Delay: Time the event waits in the queue (often due to long tasks)
• Processing Time: Time spent running event handlers
• Presentation Delay: Time for the browser to calculate layout and paint

INP Thresholds

Rating	Value
Good	≤ 200ms
Needs Improvement	≤ 500ms
Poor	> 500ms

Common Causes of Poor INP

1. Long JavaScript tasks (>50ms) blocking the main thread
2. Heavy DOM manipulation in event handlers
3. Expensive style recalculations triggered by JS
4. Third-party scripts adding main-thread work
5. Hydration overhead in framework-heavy SPAs

Optimization Techniques

Yield to the Main Thread:

// Using scheduler.yield() (new API)
async function handleClick() {
  doPartOne();
  await scheduler.yield();
  doPartTwo();
  await scheduler.yield();
  doPartThree();
}

// Fallback with setTimeout
function yieldToMain() {
  return new Promise(resolve => setTimeout(resolve, 0));
}

Use Web Workers for Heavy Computation: Move data processing, sorting, filtering, and complex calculations off the main thread entirely. The main thread should only handle UI updates.

Debounce Input Handlers: For input and keydown events that trigger expensive operations (like search), debounce the handler to avoid processing every keystroke.