When Google officially replaced First Input Delay (FID) with Interaction to Next Paint (INP) as a Core Web Vital, it fundamentally raised the bar for what it means for a website to feel “fast.”
While both metrics measure how responsive a website is when a user clicks, taps, or presses a key, they measure completely different parts of that experience.
In simple terms: FID only measured the beginning of the first click. INP measures the entire duration of every interaction throughout the entire visit.
1. The Core Difference: First Impression vs. Whole Journey
To understand why this shift matters, imagine going to a restaurant:
-
FID (First Input Delay): Measures how long it takes for the waiter to acknowledge you after you sit down and open your mouth to order (the initial delay). However, once the waiter takes your order, FID stops measuring—even if it takes 45 minutes for your food to show up or if the rest of the meal is terribly slow.
-
INP (Interaction to Next Paint): Measures the time from when you make any order or request until you actually get a visual response on your table—for every single interaction throughout your entire meal.
USER ACTION ────────► [ DELAY ] ──► [ PROCESSING ] ──► [ RENDER / PAINT ]
(Click/Tap) (Input Delay) (Event Handler) (Presentation Delay)
└─────────────┬─────────────┘
│
Old Metric (FID): Measured ONLY this first chunk (Input Delay)
New Metric (INP): Measures the ENTIRE duration until the screen updates!
2. Why Google Made the Switch
FID was too easy to pass. Around 93% of mobile sites passed FID, yet users were still complaining about slow, laggy, and freezing websites.
FID had two major flaws that INP fixes:
-
FID ignored heavy JavaScript execution: FID only measured the brief delay before the browser started processing your click. It did not measure how long the browser took to actually run the code or update what you see on the screen.
-
FID only checked the first click: If your site loaded smoothly on the initial click, but froze completely when a user clicked “Open Cart” or “Next Slide” 30 seconds later, FID marked your site as “Good.”
3. What INP Actually Measures
INP measures the total time it takes from the moment a user interacts with a page until the browser presents the next frame on the screen (visual feedback).
The INP score is calculated across three phases for every interaction:
-
Input Delay: Waiting for the main thread to be free so it can handle the user’s action.
-
Processing Time: The time spent executing the JavaScript code attached to that action.
-
Presentation Delay: The time the browser needs to recalculate the page layout and physically draw (paint) the updated pixels on the screen.
How INP is Scored: Google tracks all clicks, taps, and keypresses during a user’s session. It ignores extreme outliers and reports the single worst interaction as your page’s overall INP score.
The INP Benchmark Scale:
-
Good: $\le 200 \text{ milliseconds}$ (Feels instantaneous)
-
Needs Improvement: $200 \text{ ms} – 500 \text{ ms}$
-
Poor: $> 500 \text{ ms}$ (Feels sluggish or frozen)
4. The Practical Impact for Web Developers & Marketers
The replacement of FID with INP has major real-world consequences for how modern websites are built and optimized:
A. Heavy JavaScript Frameworks Are Under Fire
Sites relying heavily on complex JavaScript libraries (like React, Angular, or Vue) or massive third-party scripts (chat widgets, tracking pixels, heavy ad scripts) often block the browser’s “main thread.” Under FID, these sites easily passed. Under INP, they frequently fail because the browser freezes for 300ms+ while running those scripts after a button tap.
B. Immediate Visual Feedback Is Now Mandatory
Because INP measures the time until the next paint, you don’t necessarily have to finish the entire background task instantly—you just need to give the user immediate visual confirmation that their action was registered.
-
Example: When a user taps “Add to Cart,” showing an immediate loading spinner or button color change within 50ms keeps your INP fast, even if the actual database update takes 400ms in the background.
C. Dropdown Menus, Mobile Navs, and Image Carousels Fail Most Often
Real-world data shows that INP failures rarely happen on the main page link clicks. They happen on interactive elements:
-
Opening a mobile “hamburger” menu.
-
Toggling an accordion FAQ section.
-
Swiping through a product image carousel.
-
Typing into an auto-complete search bar.
5. How to Fix INP Bottlenecks
If your pages are failing INP in Google Search Console, focus your technical efforts on these three fixes:
| Problem | Technical Cause | How to Fix It |
| Long Main-Thread Tasks | Single JavaScript tasks taking $> 50 \text{ ms}$ to execute. | Break up long tasks into smaller micro-tasks using requestAnimationFrame() or setTimeout(). |
| Delayed Visual Updates | DOM updates waiting for complex background logic to finish. | Provide immediate visual feedback (e.g., set button state instantly) before running complex data processing. |
| DOM Overload | Pages with 3,000+ HTML elements take too long for the browser to recalculate layout and paint. | Reduce overall DOM size and simplify CSS layout structures (flexbox / grid). |
| Third-Party Script Bloat | Marketing tags and analytics scripts hijacking user clicks. | Defer non-essential third-party scripts or load them via web workers off the main thread. |