Interaction to Next Paint (INP) — Slow Response to User Interactions Fix
About Interaction to Next Paint (INP)
Fix high Interaction to Next Paint (INP) scores where button clicks, taps, and keyboard inputs feel sluggish due to long JavaScript tasks blocking the main thread. This guide covers everything you need to know about this topic, including common causes, step-by-step solutions, and answers to frequently asked questions.
Here are the key things to understand: INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. INP measures responsiveness: the time from user interaction to the next visual update. Google considers INP good if under 200ms, needs improvement between 200-500ms, and poor over 500ms. Unlike FID which only measured the first interaction, INP considers ALL interactions during the page lifecycle. Long JavaScript tasks (>50ms) block the main thread and delay response to user input. Understanding these fundamentals will help you diagnose and resolve this issue more effectively.
The most common reasons this occurs include: Heavy JavaScript execution blocking the main thread during user interactions. Third-party scripts (analytics, ads, chat widgets) consuming main thread time. Large DOM size causing slow rendering updates after interactions. Synchronous layout calculations (forced reflows) triggered by JavaScript. Identifying the root cause is the first step toward finding the right solution.
To resolve this, follow these recommended steps: Measure INP: Chrome DevTools > Performance tab > record interactions > check 'Interactions' track. Break up long tasks: split heavy JS work into smaller chunks using requestIdleCallback or setTimeout. Defer third-party scripts: load analytics and non-critical scripts with async or defer attributes. Use Web Workers for heavy computations to keep the main thread free for user interactions. Reduce DOM size: large DOMs (>1000 elements) cause slow style and layout recalculations. If these steps do not resolve the issue, consider consulting additional resources or a qualified professional.
This article is part of our Browser Errors collection on Error Codes Wiki. We provide comprehensive, up-to-date information to help you find solutions quickly.
Quick Answer
How is INP different from FID?
FID only measured the delay of the first interaction. INP measures all interactions throughout the page lifecycle and reports the worst (or near-worst) interaction latency. INP gives a more complete picture of page responsiveness.
Overview
Fix high Interaction to Next Paint (INP) scores where button clicks, taps, and keyboard inputs feel sluggish due to long JavaScript tasks blocking the main thread.
Key Details
- INP replaced FID (First Input Delay) as a Core Web Vital in March 2024
- INP measures responsiveness: the time from user interaction to the next visual update
- Google considers INP good if under 200ms, needs improvement between 200-500ms, and poor over 500ms
- Unlike FID which only measured the first interaction, INP considers ALL interactions during the page lifecycle
- Long JavaScript tasks (>50ms) block the main thread and delay response to user input
Common Causes
- Heavy JavaScript execution blocking the main thread during user interactions
- Third-party scripts (analytics, ads, chat widgets) consuming main thread time
- Large DOM size causing slow rendering updates after interactions
- Synchronous layout calculations (forced reflows) triggered by JavaScript
Steps
- 1Measure INP: Chrome DevTools > Performance tab > record interactions > check 'Interactions' track
- 2Break up long tasks: split heavy JS work into smaller chunks using requestIdleCallback or setTimeout
- 3Defer third-party scripts: load analytics and non-critical scripts with async or defer attributes
- 4Use Web Workers for heavy computations to keep the main thread free for user interactions
- 5Reduce DOM size: large DOMs (>1000 elements) cause slow style and layout recalculations