Fix Poor INP (Interaction to Next Paint)

What this means

Why it matters

How to fix it

1. 1

   Find the slow interactions before touching code

   Do not guess. Open Chrome DevTools, go to the Performance panel, and record while you click the buttons, menus, and form fields on the page. DevTools flags long tasks and shows which event handler ran and how long it blocked the main thread. The Web Vitals extension shows a live INP value as you interact. Cross-reference with field data in Search Console's Core Web Vitals report or PageSpeed Insights, since lab and real-user numbers diverge. Usually one or two handlers cause most of the damage, so fix those first.

2. 2

   Break up long tasks so the browser can paint

   The biggest INP killer is a long synchronous task that blocks the main thread while the user waits for feedback. Split expensive work into smaller chunks and yield control back to the browser between them so it can render. Chrome exposes scheduler.yield() for this; a portable fallback is await new Promise(r => setTimeout(r, 0)). The key move is to paint the immediate response first, such as showing a spinner or the opened menu, then do the heavy lifting. Never make the user wait for the whole computation before anything appears.

3. 3

   Defer and trim JavaScript you don't need at interaction time

   Every script the main thread parses and executes competes with your event handlers. Add defer to script tags, or use type="module", which defers by default, so parsing does not block. Code-split so heavy libraries load only on the routes that use them, and lazy-load below-the-fold widgets, third-party embeds, chat bubbles, and analytics. Audit third-party tags aggressively. Tag managers, A/B-testing scripts, and heavy analytics are frequent INP offenders because they hook into the main thread and can run on every interaction.

4. 4

   Move heavy work off the main thread or debounce it

   If an interaction triggers genuinely heavy computation such as parsing large JSON, filtering thousands of rows, or image processing, move it into a Web Worker so the main thread stays free to paint. For input-driven work like search-as-you-type or live filtering, debounce or throttle the handler so it does not fire on every keystroke. Use requestAnimationFrame for visual updates and requestIdleCallback for non-urgent background work. No single handler should occupy the main thread long enough to delay the next paint.

5. 5

   Reduce what the browser re-renders per interaction

   A fast handler can still cause slow INP if the DOM change it triggers forces a large layout or style recalculation. Avoid layout thrashing, which is reading then writing DOM geometry in a loop, and keep the DOM node count reasonable. Use CSS content-visibility: auto on large offscreen sections so the browser skips rendering them until needed. Animate with transform and opacity, which the compositor handles, rather than width, top, or height, which trigger full layout. Smaller, contained rendering work lets the next paint land faster.

6. 6

   Re-measure with field data, not just lab scores

   After deploying, INP will not update instantly in Search Console. The Core Web Vitals report is based on 28 days of rolling Chrome UX Report field data, so it lags. Use the web-vitals JavaScript library to log real INP values from your own users for faster feedback, and confirm in DevTools that the interactions you fixed now paint quickly under a throttled mid-range mobile profile (4x CPU slowdown). Aim for a 75th-percentile field INP under 200ms. The lab score is a proxy; the field number is what Google ranks on.

Example

button.addEventListener('click', async () => {
  // 1. Give instant visual feedback so the next paint is fast
  button.classList.add('is-loading');
  resultsPanel.hidden = false;

  // 2. Yield so the browser can paint the feedback above
  //    scheduler.yield() where supported; setTimeout(0) as a fallback
  await (window.scheduler?.yield?.() ??
         new Promise((resolve) => setTimeout(resolve, 0)));

  // 3. Now do the expensive work
  const rows = await filterLargeDataset(query);
  render(rows);
  button.classList.remove('is-loading');
});

// For genuinely heavy CPU work, offload it entirely:
// const worker = new Worker('/filter-worker.js');
// worker.postMessage(query);
// worker.onmessage = (e) => render(e.data);

Paint the immediate response first, then yield to the browser before running heavy work. This is the core pattern for good INP.

Platform-specific steps

Frequently asked