Why Interaction to Next Paint Is Replacing First Input Delay
When Interaction to Next Paint (INP) formally joins the Core Web Vitals as a ranking factor in March 2024, it won’t simply be another metric to track. It will replace First Input Delay (FID) entirely. The change reflects a fundamental shift in how the web platform measures responsiveness: from a narrow look at the first interaction to a comprehensive view of every interaction on a page.
Both metrics measure the same underlying experience — the time between a user action and the page’s response. But they approach it very differently. FID captures only the input delay, or the time before the browser begins processing an event handler. INP covers the full lifecycle of an interaction: input delay, processing time, and presentation delay (the time until the next frame is painted after the handler runs).
The second difference is scope. FID tracks only the page’s very first interaction, which frequently happens early in the page lifecycle or on a part of the UI the user barely touches again. INP considers every interaction a user makes with the page and reports the worst (or near-worst) one. Where FID measured a single slice of a single event, INP measures the entire event handling journey across all user actions.
Why Lab Reports Don’t Show INP
One of the first things you’ll notice when checking performance reports ahead of the March change is that INP is visible in some tools and absent from others. The reason is rooted in the type of data each tool uses.
Lighthouse and similar lab-based tools simulate page loads in a controlled environment. Because no real user is clicking, scrolling, or typing, there is no interaction to measure. Simulated data simply cannot produce meaningful INP or FID results — such metrics require field data gathered from actual browsing sessions.
To see INP in your reports, you need a monitoring tool with access to real user traffic. PageSpeed Insights draws from Google's Chrome User Experience Report (CrUX), which aggregates anonymous performance data from real Chrome users. Dedicated Real User Monitoring (RUM) tools go further, capturing data from your own visitors continuously as they browse. That live traffic view gives you far more actionable insight than periodic CrUX snapshots.
Setting Your INP Targets
Since INP captures a broader slice of the interaction lifecycle than FID, its recommended thresholds are understandably more generous. Google’s guidance places a "good" INP result at under 200 milliseconds, with anything between 200ms and 500ms considered acceptable. An interaction that takes longer than 500ms is a clear performance bottleneck worth fixing.
Don’t panic if your INP numbers run higher than your FID readings — that’s expected when measuring the entire interaction rather than just one part of the first event. The key is to spot the causes of delayed responsiveness across your page’s various components and optimize those specific interactions.
Finding Your Slow Interactions
Optimizing for INP starts with identifying which on-page elements respond slowly to user actions. An interaction might be clicking a button, expanding an accordion, or opening a modal — any action that triggers the JavaScript processing and UI updates that INP measures.
The breadth of what counts as an interaction means your page could have anywhere from a handful to thousands of measurable events. A content-focused article will naturally face fewer INP risks than a complex web application. That said, it only takes one poorly performing interaction to drag your entire INP score outside acceptable territory.
To zero in on problem areas, you have two field data routes:
- CrUX data via PageSpeed Insights, Google Search Console, or third-party tools. Using BigQuery’s historical CrUX data can extend your view back to 2017 with monthly updates. Note that some tools estimate slow-connection performance from fast-connection measurements rather than actually testing under throttled network conditions.
- Real-time monitoring by adding a snippet to your source code that forwards traffic data to a RUM service. This approach tracks your actual visitors and builds a historical record you can compare over time.
Diagnostic tools can also accelerate the process. The INP Debugger from DebugBear, for instance, analyzes any URL and then highlights the elements receiving user interactions alongside their individual INP results. The slowest element determines the page’s overall INP outcome.
When you run such a tool, you may notice its results differ from the CrUX field data — sometimes significantly. A reported 510ms result might come back as roughly 201ms faster in real-user Google data. That gap illustrates an important distinction: the diagnostic tool identifies which elements are capable of causing slow interactions, while CrUX tells you how actual users experience the page — and how frequently they interact with the problematic component. For the best INP score, both diagnostic results and real-user data should sit comfortably in the recommended range.
Where the Time Goes: The Three INP Components
Once a slow interaction has been identified — whether through field data in CrUX or a real-time monitoring tool — the optimization work can begin. The goal is to bring interaction delays under the 500ms threshold, with 200ms as the ideal target. Since INP measures three distinct phases of an interaction, each one offers a separate opportunity to cut time.
Cutting Input Delay
Input delay is the time between the user’s action, such as a click, and the start of the interaction’s callback. This is the only component that FID measures, and it is heavily influenced by main-thread activity. The Total Blocking Time (TBT) metric is a useful proxy here because it captures the CPU work that prevents the page from responding to input. While TBT is not a ranking factor, it directly affects both FID and INP, which are.
Auditing the main thread for long tasks — those exceeding 50ms — is the first step toward improving TBT. DevTools provides a clear visualization of these tasks.
The key is to optimize those long tasks. Not all scripts are equal: a core feature may depend on one script while another is just a nice-to-have. Before choosing an approach, ask: Who is the script serving? When is it served? Where is it served from? What is it serving? Then, depending on the answers, options include:
- Moving work to Web Workers to free up the main thread.
- Splitting JavaScript bundles to reduce payload sizes.
- Using
asyncordeferon scripts that don’t need to block initial load. - Preconnecting to network origins to save connection time (with a note that this may expose the user’s IP address and raise GDPR concerns).
Sometimes the simplest fix is removing scripts that are no longer needed.
Reducing Processing Time
Processing time is what happens after input delay ends, when the browser executes the interaction’s callbacks. If that work is heavy, the response can feel sluggish. A few patterns help here:
- Trigger a loading state immediately and defer the heavy work with a
setTimeout()callback, which lets the UI respond faster than waiting for the full update. - In React, avoid unnecessary component re-renders.
- Be aware that
alert(),confirm(), andprompt()run synchronously and block the main thread, adding to processing time. There are indications this behavior may change before INP becomes a Core Web Vital.
Shortening Presentation Delay
Presentation delay covers the period after callbacks finish, when the browser recalculates layout, applies styles, and paints the updated UI. Page complexity is a major factor here. Keeping the DOM smaller helps: a larger DOM means more HTML to process during both initial load and updates, even if the relationship isn’t perfectly linear. Aim for a flat DOM structure with limited nesting, and review CSS selectors for unnecessary complexity.
The content-visibility property can also help by hinting to the browser which elements should defer full rendering. This allows layout containment to be rendered while skipping paint until resources are available, though there are accessibility considerations. For pages that render HTML from JavaScript, that JavaScript must load before the HTML can appear — a cost inherent to many single-page application frameworks.
Real-User INP Breakdowns with RUM
DevTools and lab tests are useful for inspecting interactions in a controlled environment, but they don’t reflect what actual visitors experience. Real-user monitoring (RUM) answers questions like: which pages have the slowest INP? Which INP component matters most in practice? What elements do users interact with most? Are scores worse for users in certain regions? And are results improving over time?
RUM tools, such as DebugBear, provide this visibility across real sessions. DebugBear also supports the proposed Long Animation Frames API, which helps identify the source code responsible for CPU tasks in the browser.
Getting Ready for March 2024
When INP officially replaces First Input Delay as a Core Web Vital in March 2024, the measurement will shift from the first interaction to the least responsive one anywhere on the page. INP provides a more precise picture of responsiveness by combining input delay, processing time, and presentation delay into a single score.
The change is not just a metric swap; it’s a stricter evaluation of how a page handles all interactions. Identifying slow interactions now, and optimizing them before the deadline, can prevent poor user experiences and the search ranking impact of failing the 500ms threshold.
