How to Optimize for Google’s Core Web Vital INP

Interaction to Next Paint (INP) is the Core Web Vital that measures how responsive a web page feels to users. Since March 12, 2024, when Google replaced First Input Delay (FID) with INP, developers have had a more comprehensive way to evaluate real-world responsiveness. Unlike FID, which only measured the delay before the browser responded to a user’s first interaction, INP evaluates the latency of clicks, taps, and keyboard interactions throughout the page lifecycle.

But INP isn’t just a metric for SEO. When interactions feel slow, users abandon carts, bounce faster, engage less with product detail pages, and walk away from frustrating mobile experiences. Our own RUM data shows that higher INP correlates with higher bounce rates on product detail pages, providing direct evidence that responsiveness affects revenue and conversions.

Understanding what affects INP is the first step toward improving it. This article explains what INP measures, how to measure and troubleshoot it, proven techniques for improving it, and what role FID still plays as a historical diagnostic metric.

What is Interaction to Next Paint (INP)

Interaction to Next Paint (INP) measures the time from a user’s interaction, like a click or a keypress, to the next visual update on the screen.

INP is based on real user interactions across the full page lifecycle, not just the first input the way FID was. It counts clicks, taps, and keyboard interactions. Scrolling and hovering aren’t counted. INP reports a single value that represents the responsiveness a user experienced over the whole visit, so it reflects how the page behaves as people actually use it.

Because it captures the full duration of an interaction, INP gives you a detailed read on a page’s responsiveness. Google states that an INP at or below 200ms is good, 201ms to 500ms needs improvement, and above 500ms is poor.

INP reflects how responsive a page feels, so it’s one of several page-experience metrics Google considers, alongside the other Core Web Vitals. It isn’t an isolated ranking penalty on its own, but poor responsiveness can weigh on the page-experience signals that contribute to your overall SEO strategy. A slow interaction can start in front-end code, a third-party script, the Internet path between the user and your app, or the backend infrastructure behind it. That’s why it helps to connect real user experience with Internet dependencies and infrastructure health, so you can see where a slow interaction actually begins.

INP vs FID: a comparison

FID measured the delay from a user’s first interaction with a page to the moment the browser could begin responding. It only looked at that initial input delay, so it didn’t account for the total time needed to update the visual response.

INP address that drawback by including the complete lifecycle of an interaction: input delay, processing time, and presentation delay. It also looks across every qualifying interaction in a visit rather than a single one. That makes it a more comprehensive metric.

Key components of INP

1. Input delay: the time from user input to the start of event processing.
2. Processing time: the time the browser takes to run event handlers and callbacks.
3. Presentation delay: the time until the next frame is rendered and displayed.

How to measure INP

You can measure INP with both Real User Monitoring (RUM) and synthetic monitoring. Google recommends starting with RUM, since it reflects what actual users experience. Field data from sources like Google’s Chrome User Experience Report (CrUX) can tell you whether a page has an INP problem, while RUM helps you identify the cause by tying the score to specific pages, interactions, and conditions. Once RUM detects the problem areas, synthetic monitoring lets you reproduce and diagnose them under controlled conditions. Together they keep your attention on the issues that matter most to performance.

Through LogicMonitor’s unified platform, that RUM and synthetic data works alongside visibility into the Internet path and the underlying infrastructure. So when INP climbs, you can trace it from the user’s browser back through the delivery path to the systems serving the page.

INP troubleshooting workflow

High INP scores can result from many different issues, from JavaScript execution to rendering delays. Following a repeatable workflow helps you identify the true source of the problem and prioritize the fixes that will have the greatest impact.

1. Find poor-INP pages in RUM: use real user data to see which pages exceed the 200ms threshold and for which users.
2. Identify the slow interaction: pinpoint the specific click, tap, or keypress that produced the high score, using interaction attribution.
3. Break down the timing: separate input delay, processing duration, and presentation delay to see which part of the interaction is slow.
4. Reproduce in lab or synthetic: recreate the interaction in a controlled environment, for example with WebPageTest, so you can profile it repeatably.
5. Optimize the cause: address the JavaScript, rendering work, or third-party scripts driving the delay.
6. Monitor after release: confirm the fix in field data and watch for regressions as conditions and user behavior change.

The role of FID after deprecation

Google has deprecated FID and removed it from the Core Web Vitals program, so INP is the responsiveness metric teams should optimize against. FID is no longer an active Core Web Vital.

Why FID can still be a useful diagnostic

Even after deprecation, FID can serve as a diagnostic, historical metric for input delay specifically. Because it isolates the input-delay portion of an interaction, a historical FID reading can help you reason about where INP time is being spent.

Consider a page with a strong FID but a poor INP caused by extended processing or presentation times. Reading a historical FID value alongside INP can guide where to focus your optimization work. If FID was good but INP is poor, the problem likely lies beyond input delay, in processing or rendering. If FID itself was poor, the initial response to user input is a good place to start. INP remains the metric to optimize against; FID is context, not a target.

To show how the two signals relate, let’s look at some real-world data.

Example 1

In one study of a page’s performance, FID at the 95th percentile came in at 100ms, well within the “good” range. The corresponding INP value was 576ms, far above the 200ms threshold (see the Example Trend A chart below).

The page responds quickly to the first interaction, but overall interactivity suffers from longer processing or rendering times.

Example 2

In some cases, slow input delay contributes to a poor INP, which shows how the timing components connect. In the scenario below, INP performance is poor and input delay is contributing to that degradation.

Reading both signals together gives you a fuller picture of a fast, responsive user experience.

Key steps to optimize INP

Now that we’ve covered why INP monitoring matters to user experience, here are some best practices to improve the metric. INP is driven mainly by main-thread work during interactions, not by general page load, so the most direct levers are the JavaScript and rendering work that run when a user clicks, taps, or types.

These seven steps give you a practical starting point:

1. Use RUM to find and attribute slow interactions: track real user data to identify which interactions are slow and attribute them to specific pages and elements. If users hit delays while adding items to a cart, for example, RUM can surface it.
2. Use synthetic testing: once you’ve identified problem areas, set up synthetic tests to reproduce them and diagnose root causes under controlled conditions.
3. Reduce long tasks and main-thread contention: break up long tasks so the main thread stays free to respond, and cut work that competes for the thread during interactions, including heavy hydration on interactive pages.
4. Trim event handler and callback duration: keep the code that runs in response to a click, tap, or keypress short, so processing time stays low.
5. Optimize first-party and third-party JavaScript: minify and defer non-essential scripts, and audit third-party JavaScript that runs on the main thread during interactions.
6. Speed up rendering and presentation work: reduce the rendering work needed to paint the next frame so presentation delay stays short. Faster content load helps indirectly by getting the page interactive sooner, but rendering and presentation are the more direct levers.
7. Continuously monitor and iterate: review your INP scores and interaction attribution regularly, then use that data to make ongoing improvements as conditions and user behavior change.

Let’s look at specific examples of how these optimizations improve INP.

Impact of JavaScript optimization on INP

In the example below, notice how optimizing JavaScript, specifically by minifying both first-party and third-party scripts, improves the Interaction to Next Paint (INP) metric. Less script to parse and execute means less main-thread work during interactions, which is what INP measures.

This shows the proportional impact JavaScript optimization can have on INP. By reducing the size and complexity of JavaScript files through minification and selective loading, the page keeps the main thread free and becomes noticeably more responsive to user interactions.

Impact of content load time optimization on INP

In the chart below, notice how reducing content load time, the time it takes to load a page’s main content, improves the INP score. This helps indirectly: when the page settles sooner, the main thread has less competing work when a user interacts.

When the main content loads faster, the main thread is less contended during interactions, so the whole interaction process becomes more responsive, which leads to a better user experience.

Measure and optimize INP with LogicMonitor

Optimizing INP comes down to a diagnostic workflow: find the slow interactions, trace them to a cause, and fix them across the full path from user experience to Internet path to infrastructure. The outcome is pages that respond fast and hold onto users, revenue, and engagement. LogicMonitor covers that entire workflow, connecting what users experience in the browser to the Internet dependencies and the infrastructure serving your pages, so you can find where a slow interaction begins.

LogicMonitor’s Real User Monitoring (RUM) enables you to track all Core Web Vitals, including INP. It offers detailed analysis with customizable data views and visualizations, so you can identify the pages and interactions to improve.

This dashboard shows a high INP correlating with an increased bounce rate on product detail pages (PDP). Insights like these point to exactly where a site is losing users, which is how you connect a responsiveness score to business impact.

WebPageTest provides accurate, detailed performance metrics to reproduce and profile slow interactions.

Alongside WebPageTest metrics, you’ll find additional data, including INP, gathered from Google’s CrUX report. CrUX gives you an INP score based on real user experiences, and RUM helps you pinpoint and understand the root causes behind that score. Edwin AI can act as the intelligence layer on top of this data, helping correlate metrics across experience, Internet path, and infrastructure so you can prioritize which slow interactions to fix first.

INP is where front-end performance, user experience, and business impact converge. By measuring, monitoring, and improving it, you keep your pages fast and responsive, protect conversion and engagement, and support the page-experience factors that help your pages rank well.

FAQs

By Denton Chikura

Technical Writer

Denton Chikura is a technical writer and longtime observability advocate focused on helping site reliability engineers and engineering teams discover the tools and capabilities that strengthen internet resilience. He works at the intersection of monitoring, performance, and infrastructure to make complex systems more understandable and usable, bridging the gap between deep technical detail and real‑world operations. His goal is to help teams build faster, detect issues earlier, and recover smarter, ultimately making the internet a better, more reliable place for everyone.

Disclaimer: The views expressed on this blog are those of the author and do not necessarily reflect the views of LogicMonitor or its affiliates.