Interaction to Next Paint (INP) measures the latency between a user's interaction — a click, tap, or keyboard press — and the next frame the browser paints in response, capturing overall page responsiveness throughout the full visit.
Quick Answer
Interaction to Next Paint (INP) measures the latency between a user's interaction — a click, tap, or keyboard press — and the next frame the browser paints in response, capturing overall page responsiveness throughout the full visit.
INP measures all interactions throughout the page visit, not just the first — making it a more comprehensive responsiveness metric than its predecessor FID.
Breaking up Long Tasks using scheduler.yield() or setTimeout is the most direct way to reduce input delay and improve INP.
Third-party scripts are a leading cause of high INP and should be audited and loaded with defer or triggered post-interaction to minimize main thread blocking.
Key Takeaways
INP measures all interactions throughout the page visit, not just the first — making it a more comprehensive responsiveness metric than its predecessor FID.
Breaking up Long Tasks using scheduler.yield() or setTimeout is the most direct way to reduce input delay and improve INP.
Third-party scripts are a leading cause of high INP and should be audited and loaded with defer or triggered post-interaction to minimize main thread blocking.
How Interaction to Next Paint Works
INP is calculated by observing the latency of every interaction a user makes with a page during their visit and reporting a high percentile (approximately 98th percentile) of those interaction latencies as the page's INP score. An interaction latency consists of three phases: the input delay (time from user action to when the browser begins processing the event handler), the processing time (time the event handler takes to execute), and the presentation delay (time from handler completion to the next frame painted). Reducing any of these three phases improves INP.
Why Interaction to Next Paint Matters for B2B Marketing
Long Tasks on the main thread are the primary source of high input delay. A Long Task is any JavaScript execution that blocks the main thread for more than 50 milliseconds, preventing the browser from processing user inputs during that window. Breaking up Long Tasks using scheduler.yield(), setTimeout with zero delay, or Web Workers allows the browser to process user interactions between chunks of work. This is particularly important for complex single-page applications that perform heavy computation on the main thread during page lifecycle events.
Interaction to Next Paint: Best Practices & Strategic Application
Third-party scripts — analytics, chat widgets, advertising tags, heatmap tools, and social embeds — are frequent INP offenders because they execute JavaScript on the main thread at unpredictable times, often during user interaction windows. Auditing third-party script performance using the Chrome DevTools Performance panel reveals which scripts are contributing to Long Tasks. Loading non-essential third-party scripts with async or defer attributes, or using a tag manager to delay their firing until after first user interaction, mitigates their impact on INP.
Agency Perspective: Interaction to Next Paint in Practice
React and other single-page application frameworks can produce high INP scores when state updates trigger large component re-renders synchronously on the main thread. React's concurrent features (useTransition and useDeferredValue) allow expensive re-renders to be interrupted and deferred, keeping the main thread available for user input processing. For non-React sites, minimizing DOM manipulation complexity, reducing event handler execution time, and avoiding forced layout reflows inside event handlers are the most effective optimization strategies.
Frequently Asked Questions: Interaction to Next Paint
Interaction to Next Paint (INP) measures the latency between a user's interaction — a click, tap, or keyboard press — and the next frame the browser paints in response, capturing overall page responsiveness throughout the full visit.
First Input Delay (FID) measured only the delay before the browser began processing the very first user interaction on a page, ignoring processing time, presentation delay, and all subsequent interactions. INP measures the latency of all interactions throughout the full page session and reports near-worst-case performance, capturing slow interactions that occur after the page has loaded but while the user is actively engaging. INP is a significantly more demanding and realistic measure of whether a page feels responsive to use.
Use the Chrome DevTools Performance panel to record a session and reproduce the slow interaction. Look for Long Tasks (marked in red) that overlap with the interaction's timing. The Bottom-Up and Call Tree views identify which JavaScript functions are consuming the most execution time. The LoAF (Long Animation Frames) API, available in Chrome 123+, provides even more granular data about which scripts caused frames to take longer than 50ms. The Web Vitals extension can also log INP candidates in the console during your browsing session.
Indirectly, yes. If a user interaction triggers a network request (such as a fetch call to an API) and the UI is blocked while waiting for the response, slow server response times can appear to cause high INP. However, true INP measures only the browser's main thread processing, not network wait time. If the network request is made asynchronously and the UI remains responsive while waiting, it does not directly inflate INP. The fix for network-induced perceived slowness is to show immediate visual feedback (loading states, optimistic UI updates) while the request is in flight.
MV3 Marketing helps B2B companies apply these strategies to drive measurable pipeline growth. Our team executes our services for technology, SaaS, and professional services companies.
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager
1 minute
_gac_
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked