Interaction to Next Paint (INP) measures how quickly a website responds visually after someone clicks, taps, or presses a key. It replaced First Input Delay (FID) as a Core Web Vital because responsiveness is not only about the first interaction — it is about whether the site stays responsive throughout the visit.
For a business website, poor INP can feel like a menu that hesitates, a form button that reacts late, or a filter that appears frozen after the page has loaded.
What INP Actually Measures
INP looks at the full latency of user interactions.
According to web.dev's INP guidance, an interaction can be broken into three parts:
- input delay — the time before the browser can start handling the interaction;
- processing duration — the time spent running event handlers;
- presentation delay — the time between finishing that work and painting the next frame.
A page can achieve a strong Largest Contentful Paint and still feel sluggish if JavaScript keeps blocking the main thread.
What Replaced FID — and Why?
FID measured only the delay before the browser started processing the first user interaction.
INP is broader.
It considers interactions across the page's lifecycle and measures the experience from the input through processing and the next visual update. For most pages, the slowest interaction is what matters.
INP officially replaced FID as a stable Core Web Vital in March 2024.
The change matters because one fast first click should not hide slow interactions later in the visit.
What Is a Good INP Score?
Google's current thresholds are:
- 200 milliseconds or less: good;
- more than 200 ms to 500 ms: needs improvement;
- more than 500 ms: poor.
These thresholds are evaluated at the 75th percentile of page visits.
The goal is not zero delay; it is fast enough response that users do not notice hesitation.
What Poor INP Feels Like to a Visitor
A poor INP score usually maps to a very ordinary frustration.
Examples include:
- opening a mobile menu and waiting for it to appear;
- clicking "Book a Consultation" and seeing no immediate feedback;
- choosing a filter while the interface pauses;
- typing into a form that feels delayed;
- expanding an accordion and seeing it respond late;
- adding an item to a cart while the button appears stuck.
Often the frustration comes from the website failing to acknowledge the interaction quickly.
The Three Main Causes of Slow INP
1. High input delay
The user interacts, but the browser's main thread is already busy.
Long JavaScript tasks, third-party scripts, analytics, hydration, or expensive initialization can keep the browser from starting the interaction promptly.
2. Slow event-handler processing
The browser starts handling the click or keypress, but the handler itself does too much work.
Examples include:
- filtering a large dataset in one task;
- performing expensive calculations;
- manipulating many DOM elements;
- running multiple event handlers;
- triggering synchronous third-party code.
The solution is usually to reduce the work, split long tasks, or move suitable heavy computation off the main thread.
3. High presentation delay
The JavaScript finishes, but the browser still needs significant layout, style, or rendering work before it can show the result.
A very large DOM, expensive layout calculations, complex visual updates, or large synchronous rendering changes can all contribute.
Chrome's INP breakdown guidance recommends fixing whichever of these three phases is actually slowest.
Use the REACT Framework
Veil Vertex uses a simple way to troubleshoot website INP:
R — Record the slow interaction: Identify the actual click, tap, or key interaction that feels delayed.
E — Examine the phase: Determine whether the problem is input delay, processing, or presentation.
A — Avoid long main-thread tasks: Break up non-critical JavaScript and defer work that does not need to block the interaction.
C — Cut interaction work: Simplify event handlers, DOM updates, and unnecessary third-party code.
T — Test with real users: Confirm the change improves field INP, not only one fast desktop test.
This keeps optimisation focused on the interaction users actually struggle with.
How to Diagnose INP Properly
Start with field data when available.
PageSpeed Insights and Chrome UX Report data can show how real users experience the site. Then reproduce the slow interaction in Chrome DevTools.
The Performance panel can reveal long main-thread tasks, slow handlers, layout work, rendering delay, and third-party script activity.
Test important journeys, not only the homepage. Check actions such as:
- opening navigation;
- submitting or advancing forms;
- opening accordions;
- changing tabs;
- using search or filters;
- booking or checkout interactions;
- opening chat or scheduling widgets.
Because INP is an interaction metric, diagnosis requires interacting with the page.
Reduce Long JavaScript Tasks
Long tasks that keep the main thread busy are a common cause of poor INP. Useful fixes include:
- breaking large tasks into smaller chunks;
- yielding back to the browser between units of work;
- reducing unnecessary JavaScript;
- delaying non-critical scripts;
- removing unused plugins;
- using a Web Worker for suitable heavy computation;
- simplifying component rendering.
Do not judge JavaScript only by bundle size. A smaller file can still execute expensive code at the wrong time.
Audit Third-Party Scripts
Chat widgets, analytics, A/B testing tools, review widgets, advertising scripts, schedulers, and tag-manager containers can all consume main-thread time.
That does not mean every third-party tool should be removed. Ask whether it must load immediately, run on every page, or could use a lighter implementation.
Several "small" marketing tools can collectively create a larger problem than one obvious script.
Keep the DOM and Visual Updates Manageable
A large, deeply nested DOM can increase style and layout cost. Updating hundreds of elements at once can also create a large presentation delay.
Update only what needs to change and avoid rebuilding large interface sections for a small interaction.
INP Is Different From Page-Load Speed
Largest Contentful Paint tells you how quickly major loading content appears.
Time to First Byte helps diagnose how long the initial response takes to start.
INP tells you whether the site remains responsive after someone starts using it.
A site can pass one metric and fail another.
INP Checklist for a Business Website
Before changing frameworks or rebuilding the site, check:
- Is field INP above 200 ms?
- Which real interaction is slow?
- Is the delay before the handler, inside the handler, or before paint?
- Are long JavaScript tasks blocking the main thread?
- Are event handlers doing more work than necessary?
- Are third-party tools running during critical interactions?
- Does the page have an unnecessarily large DOM?
- Can heavy work be split, deferred, or moved off the main thread?
- Do important buttons give immediate visual feedback?
- Does the improvement show up in real-user data?
The best fix removes the actual delay users experience.
Fast Websites Should Feel Fast After They Load
A page is not truly fast if it loads quickly and then hesitates when someone tries to use it. INP measures that responsiveness across the visit.
Find the slow interaction, identify which phase causes the delay, reduce main-thread work, and test the result under realistic conditions.
If your website loads quickly but still feels sluggish during forms, menus, filters, or booking flows, Veil Vertex can identify the interaction bottleneck through a free tailored website audit.