Optimizing Web Vitals: INP Performance

Legacy FID measured only the time between a user's initial click and when the browser's main thread became available to start executing event listeners. FID completely ignored the time spent executing event handler logic or rendering visual UI updates to the screen.

Interaction to Next Paint (INP) measures total end-to-end interaction latency: $$\text{INP Latency} = \text{Input Delay} + \text{Processing Duration} + \text{Presentation Delay}$$

INP evaluates the single worst interaction latency (or 98th percentile for pages with many interactions). An INP under 200ms is considered 'Good', 200ms–500ms 'Needs Improvement', and >500ms 'Poor'. For Core Web Vitals optimization, review optimizing frontend performance core web vitals and observable state management react.

Diagnosing slow INP requires identifying which sub-phase is consuming the main thread:

1. Input Delay: Time spent waiting for previous long tasks running on the main thread to complete before the browser can trigger the interaction's event listener. 2. Processing Duration: Time spent executing JavaScript code inside event listeners (onClick, onKeyDown). Heavy synchronous data filtering or DOM recalculations block this phase. 3. Presentation Delay: Time required by the browser compositor engine to recalculate CSS layout (reflow), paint pixels (repaint), and composite layers to render the updated frame to the GPU.

Any JavaScript task executing for >50ms is classified as a Long Task. Long tasks block the main thread and degrade INP.

### 1. Yielding the Main Thread with scheduler.yield() Modern browsers support the prioritize-yielding API scheduler.yield(), which yields control back to the browser compositor to draw a paint frame before continuing task execution:

1async function handleFilterButtonClick(items) {2  // 1. Immediately update UI spinner3  showSpinner();4  await scheduler.yield(); // Yield to main thread for fast paint!5 6  // 2. Heavy filtering logic in chunked batches7  const results = processHeavyDataset(items);8  renderResults(results);9}

### 2. Offloading Compute to Web Workers Move non-DOM computational tasks (JSON parsing, data transformation, state diffing) off the main thread entirely into a background Web Worker thread.

Capturing real-user INP metrics (RUM - Real User Monitoring) is essential for validating performance improvements in production:

1import { onINP } from 'web-vitals';2 3onINP((metric) => {4  // Send INP metric & interaction target element to analytics backend5  const body = JSON.stringify({6    value: metric.value, // e.g. 142ms7    rating: metric.rating, // 'good' | 'needs-improvement' | 'poor'8    element: metric.entries[0]?.target?.tagName,9  });10  navigator.sendBeacon('/api/analytics/vitals', body);11});

In local development, use Chrome DevTools Performance Panel -> Interactions track to inspect interaction frame timings and trace CPU execution stack traces.