Fix INP — Improve Interaction to Next Paint & Responsiveness

Introduction — Why INP Matters for Real Users

Interaction to Next Paint (INP) measures how quickly a page responds and visually updates after a user's interaction. Unlike single-moment metrics that only capture the first input, INP evaluates responsiveness across real interactions, helping you identify slow event handlers, main-thread blocking, and layout bottlenecks that make a site feel sluggish.

This article gives a focused audit workflow: how to measure INP, identify root causes, and apply targeted fixes that reduce input latency and get the next paint to occur promptly. Use this as a practical checklist you can apply to production and staging environments.

Step 1 — Measure INP: Field and Lab Signals

Begin with clear measurements so you know whether changes help real users.

Field data: Collect INP from real users via RUM. Use the official Web Vitals approaches (e.g., the web-vitals library) or your analytics provider to capture interaction latencies across sessions.
Lab data: Reproduce problem flows in Chrome DevTools Performance panel or Lighthouse. Measure representative interactions (clicks, taps, keyboard events) and capture the trace to identify long tasks and main-thread time during those interactions.
Define key interactions: Map the most common or business-critical interactions (navigation clicks, form submissions, toggles). Prioritize those that cause the worst INP for remediation.

Quick instrumentation example (web-vitals)

import {getINP} from 'web-vitals'
getINP(metric => console.log('INP', metric.value, metric))

Log or send this metric to your analytics backend to track progress after fixes.

What to look for in traces

Long Tasks (tasks > 50 ms) overlapping with input handlers.
Large JavaScript execution before paint — scripts that run synchronously and block the main thread.
Layout & style recalculation chains (forced synchronous layouts / layout thrashing).
Heavy rendering or expensive paint operations immediately after input.

Step 2 — Root Causes & Targeted Fixes

Fixes should be surgical: reduce the work that runs between input and the next paint. Below are common root causes with concrete remediation patterns.

1. Long JavaScript tasks

Fix: Split long tasks into smaller chunks (slice using setTimeout/setImmediate/requestIdleCallback) or move heavy work to Web Workers.
Expected effect: Shorter main-thread tasks let input handlers run and schedule paints quickly.

// Split work into smaller chunks
function processLargeArray(items) {
  let i = 0
  function chunk() {
    const end = Math.min(i + 200, items.length)
    for (; i < end; i++) heavyOp(items[i])
    if (i < items.length) setTimeout(chunk, 0)
  }
  chunk()
}

2. Synchronous layout and forced reflow

Fix: Batch reads and writes: read all layout values first, then write styles. Avoid patterns that repeatedly read layout after writes (layout thrash).
Fix: Use CSS transforms and opacity for animations so the compositor can handle paints without layout.

3. Heavy work inside input handlers

Fix: Make input handlers minimal—only record intent and schedule heavier work asynchronously via requestAnimationFrame/requestIdleCallback or microtasks carefully.
Example: Use requestAnimationFrame to schedule DOM updates that should paint on the next frame.

element.addEventListener('click', (e) => {
  // Quick: record and early return
  recordUserAction(e)
  // Defer heavy DOM update to next frame
  requestAnimationFrame(() => {
    performDOMUpdate()
  })
}, {passive: true})

4. Third-party scripts and analytics

Fix: Lazy-load or defer nonessential third-party scripts, sandbox and isolate slow tags, and use async loading patterns.

5. Reduce cost of rendering and paint

Fix: Simplify complex CSS selectors, reduce expensive CSS (heavy box-shadows, complex filters), and avoid large offscreen repaints triggered by input events.

Step 3 — Practical audit checklist & priority table

Priority	Action	Why it helps
High	Make input handlers <= 50ms; defer heavy work	Ensures quick response and allows next paint
High	Remove long tasks during common interactions	Reduces blocking of the main thread
Medium	Use Web Workers for parsing/processing	Shifts compute off main thread
Medium	Batch DOM reads/writes; avoid forced layouts	Prevents layout thrashing and extra paints
Low	Lazy-load nonessential scripts and images	Frees main-thread for immediate input handling

Step 4 — Verification and Monitoring

Re-run lab traces for the same interaction flows and compare traces before/after fixes.
Monitor INP in production RUM dashboards and track distribution (not just averages). Focus on the worst interactions and the percent of users experiencing poor INP.
Automate regression checks in CI by simulating interactions and ensuring no new long tasks appear.

Conclusion — Real gains from targeted changes

INP-focused audits are effective because they focus on the real feel of responsiveness. Small, targeted changes—making handlers cheap, splitting heavy work, and avoiding layout thrash—often produce big improvements. Use lab traces to find the worst offenders, implement surgical fixes, then confirm with real-user metrics.

Use this guide as an audit template. Start by identifying the highest-impact interactions, apply the fixes above, and measure INP in production to ensure users see the improvements.

INP-Focused Audits: How to Fix Interaction to Next Paint and Improve Real-World Responsiveness