Core Web Vitals Update: INP Replaces FID

How you perform in search engine rankings depends on many factors – including your website’s response time. While content and backlinks provide visibility, whether users stay is determined, among other things, by fast, noticeable interactions.

Since March 2024, Google has therefore been evaluating responsiveness with the Interaction to Next Paint (INP) metric. The metric replaces FID (First Input Delay) and focuses on a simple question: How quickly does your page react visibly when someone clicks or types?

For marketers and CMOs, this is a clear mandate, as conversion and revenue are directly affected. In the future, knowing how the INP metric is calculated, what values are desirable, and which measures can improve them will be a competitive advantage.

What is INP?

INP (Interaction to Next Paint) is a Core Web Vitals metric for responsiveness. It measures how quickly your website reacts to a user action. Specifically, this value shows how fast your page renders something visible (visual feedback) after an interaction (e.g., a click).

Google’s goal was to measure responsiveness more realistically than with its predecessor, FID. Technically, INP is based on the Event Timing API (W3C), which provides latencies of real user actions in the browser.

Google first introduced INP as an experimental metric in 2022, announced the switch from FID to INP in 2023, and made INP an official Core Web Vital on March 12, 2024. Since then, INP has been considered the most important metric for responsiveness and appears in CrUX, PageSpeed Insights, and the Google Search Console as a field metric. Interaction to Next Paint is thus the most precise metric for perceived responsiveness.

How is the INP metric measured?

INP observes all qualified interactions after a user interacted during their entire visit and reports the worst representative interaction as its value. It measures the time from the user action to the next visible frame.

INP only considers specific interactions. Zooming and scrolling are excluded; instead, INP only takes into account mouse clicks, taps on a touchscreen, or key presses (on-screen and physical).

INP itself is composed of three parts (or time periods):

• Input Delay: After the handler’s work is complete, it takes time to make the change visible on the screen (the browser renders layout and pixels). This is the Presentation Delay.
• Processing Time: During this period, the event handler runs, and the work it triggers (e.g., calculations, DOM changes) is executed.
• Presentation Delay: After the handler’s work is complete, it takes time to make the change visible on the screen (the browser renders layout and pixels). This is the Presentation Delay.

These three components combine to determine the final INP value, leading to the following formula:

INP = Input Delay + Processing Time + Presentation Delay

And what about outliers? It can certainly happen that the same interaction is fast one time but takes much longer another time.

Google has a solution for this: Across many visits, they aggregate the visit values in the Chrome User Experience Report over a rolling 28-day window and evaluate the 75th percentile (P75). Mobile and desktop performance are also considered separately.

What are INP thresholds?

INP is classified into three categories, each with assigned thresholds. These form a kind of rating and traffic-light system based on field data and real user experience.

Color	Threshold	Description
Green	≤ 200 ms	This is a good INP value; users perceive an immediate response.
Yellow	> 200 ms bis ≤ 500 ms	The value needs improvement. You should take action.
Red	> 500 ms	The response is sluggish and immediate action is required.

Is INP better than FID?

Yes, because INP better reflects perceived responsiveness than FID. FID only measures the first interaction and only the input delay. This means it doesn’t capture anything that happens after the event handler starts. INP, on the other hand, takes the worst representative value of all relevant interactions and measures not only the input delay but also the Processing Time and Presentation Delay. So, there are good reasons why INP has replaced its predecessor in the Core Web Vitals metrics:

• The first interaction alone is not representative enough for the entire session.
• FID does not capture pages with JavaScript that create long tasks and trigger rendering work.
• INP can better reflect the user’s perception because it measures how quickly visual feedback is provided.

Why is INP a management issue?

Because response time drives revenue. INP shows how quickly your page responds visibly. Slow interactions cost leads, increase the cost per acquisition (CPA), and weaken rankings. However, you cannot address this through technology alone; instead, management through goals, budget, and prioritization plays a crucial role. CMOs are in the right position to initiate these measures.

What does the INP Core Web Vitals update mean for website operators?

INP is now the benchmark for perceived responsiveness – and companies are measured by it using real user data. This therefore affects ranking, conversion, and even the roadmap.

Response time has always been a factor, as Google’s analyses have shown. For example, about 53% of users abandon a mobile site if it doesn’t load within 3 seconds. INP goes a step further by evaluating relevant interactions that are important for leads.

INP can introduce new requirements for the website, but also provide valuable insights for improvement. Depending on your starting point, you may face potential advantages and disadvantages:

Aspect	Possible Advantage	Possible Disadvantage
INP as Core Web Vital	Clear quality KPI for product and marketing	Resource requirement for implementation
Measurement with field data (CrUX/RUM)	Realistic control, less flying blind	Improvements are reflected with a delay (28 days)
Focus on interactions	Better UX in critical journeys (forms, filters) and lower bounce risk	Redesigns of UI/Flows necessary
Third-Party-Governance	Less dependency on vendor lag, fewer main-thread blocks	Resistance in the tracking stack
Prioritization by impact	Higher ROI per sprint and potentially better ranking stability	Effort for analysis and alignment
Framework optimizations (SPA)	Faster app experience and better core signals	Technical complexity

How to build an INP database?

To manage INP as a lever for ranking and conversion, you should set up a RUM system. RUM stands for Real User Monitoring and involves collecting real user data. You measure what happens on real devices, networks, and browsers, and attribute each measurement to a journey, an element, or a script source.

While lab tests are helpful for debugging, a RUM setup helps you to implement targeted fixes and improve web performance.

How to set up a RUM system

A RUM setup includes the following criteria:

• Objective: What value are you aiming for as a target? What do you want to improve?
• Measurement Tool: You need a measurement snippet in the frontend.
• Sampling: To reduce costs, measuring a sample is often sufficient. However, the sample should not be too small to remain representative.
• Attribution: Using context fields, you can pinpoint what, when, where, and by whom something was caused. This helps answer questions about which user interactions occurred, which scripts caused delays, which element was affected, etc. It is therefore crucial for quickly identifying root causes.
• Segmentation: A meaningful division into different segments helps with troubleshooting. For example, measures for mobile INP or desktop INP often require different approaches.
• Data Privacy: Do not store personal data, comply with data protection regulations, and define usage and access rights.
• Event Schema: A unified, comparable, and analyzable measurement requires an event schema. This defines which fields you store for each measured interaction.
• Reporting: A monthly C-level report on INP P75 for top journeys, separated by mobile and desktop, plus a 28-day trend is recommended. The operational team, however, should receive a weekly list of the slowest interactions. Set up alerts and clarify ownership.

The 3 practical options

In practice, there are three ways you can start measuring:

1. Quick Start: You integrate a lightweight snippet, set up sampling, and send events via sendBeacon to your analytics/RUM. After a few days, you’ll have a baseline of slow interactions, affected elements, and script sources to get started with.
2. Tool-Based: Combine Google Search Console and PageSpeed Insights/CrUX for trends with a RUM tool (self-hosted or SaaS) for root cause lists and alerts. The advantage is that ready-made dashboards, segmentation, and regression warnings are already available, making it easy to scale.
3. Enterprise or Custom: You can operate your own RUM backend and link it with events, releases, feature flags, or error monitoring. With attribution, you can build custom C-level and operations reports and gain maximum control. While this is the most complex method, it is perfect for complex setups.

What are the possible causes of a poor INP?

INP is influenced by how quickly the event handler starts, how long it runs, and how fast the next visible frame appears. A poor INP value, a clear sign of poor responsiveness, therefore usually occurs when the browser has to do too much at once, causing it to slow down. Specifically, the following aspects can be responsible:

• Blockage of the main thread by large JavaScript bundles or polyfills
• Interaction congestion due to long tasks > 50 ms
• Heavy event handlers and synchronous processing
• Lack of prioritization, mixing critical actions with secondary tasks
• Lack of offloading to background threads
• Numerous or unnecessary DOM changes
• Lack of immediate visual feedback
• Complex effects, large images/icons, or late-loading web fonts
• Blockage by third-party scripts
• Render-blocking patterns
• Weak devices/browsers (especially on mobile)
• Regressions from new releases
• SPA hydration/routing that is too heavy or poorly timed

How can you improve INP?

Improve INP by unloading the main thread, using lean event handlers, and rendering immediate visible feedback. In practice, this can involve various measures, such as breaking down long tasks, reducing rendering work, and splitting JavaScript.

However, don’t be fooled by common misconceptions. A good Lighthouse score does not mean a good Interaction to Next Paint score. This process of optimizing INP is crucial for user retention. Lighthouse helps with debugging, but Google evaluates field data (RUM/CrUX/GSC). This INP data provides the most accurate picture. Furthermore, it’s not enough to fix the metric just once, as new releases and tags can change the results.

Therefore, implement a dashboard and regularly check the success of your measures to adapt them. If you know whether the cause lies in the Input Delay, in the Processing Time, or in the Presentation Delay, you can then take appropriate action.

Speeding Up the Initial User Input

To make the handler start faster, you should unload the main thread. Break up long tasks, split or reduce scripts, minify and tree-shake your JavaScript, and rethink loading strategies. Prioritize interaction-critical processes and visible feedback. Lazy loading, for example, is suitable for below-the-fold components.

Define a tag budget and keep critical paths clear. If chats, heatmaps, or other elements are burdening the main thread, do not initialize them above the fold. Also, check which third-party scripts are already running and, if possible, defer them.

Optimizing Interaction Processing

For faster processing time, you should streamline the event handler. Do only what is absolutely necessary within the click event itself. Everything else can run later. Large loops, complex validations, and synchronous JSON parsing are out of place here. Instead, move computationally intensive work to a Web Worker.

Process data asynchronously and in small chunks instead of all at once. Use debounce/throttle when many events fire in quick succession, and cache results that you reuse (e.g., already loaded data). Also, only load the data the user actually needs right now.

Delivering Faster Visual Updates

The presentation delay decreases the faster the user receives visual feedback. You can achieve this by changing button states, displaying skeletons, or using lightweight animations. Keep DOM updates small. Batch changes together, avoid layout thrashing, and schedule UI work with requestAnimationFrame.

Use CSS containment so the browser has less to recalculate. Prefer GPU-friendly properties like transform and opacity over expensive reflows. Avoid effects (e.g., large shadows, filters) and overly large images. Instead, compress images and deliver static resources via a CDN with active browser caching. Load web fonts with font-display, use lazy loading for media, and avoid unnecessary repaints.

Conclusion: Improve INP and Your Ranking

INP shows you how quickly your page responds visibly after a click. This factor not only affects your ranking on the World Wide Web but also provides you with important insights and areas for optimization.

Although initial investments in analysis and measures are required, in the long run, these actions can have a positive impact on ranking, conversion, and acquisition costs.

To achieve this, build a reliable database with RUM and prioritize top journeys based on the measured timings. Choose appropriate INP measures to positively influence the entire Interaction to Next Paint lifecycle and build a competitive advantage.

However, remember that this is an ongoing process, as releases and campaigns can change the values and may require new adjustments for you to remain in the top rankings.

FAQ – The most important questions about INP

What is INP and what’s behind it?

INP (Interaction to Next Paint) measures how quickly your website visibly responds to a user action. It captures clicks, taps, and keyboard inputs throughout the entire visit. The slowest representative value from these interactions is reported as the INP. The metric consists of three parts: Input Delay (until the handler starts), Processing Time (how long the handler runs), and Presentation Delay (until the next visible frame appears).

Is INP part of the Core Web Vitals Metrics?

Yes, since March 12, 2024, INP has been an official part of the Core Web Vitals, replacing its predecessor, FID. Google uses field data at the 75th percentile for its calculation, considering Mobile INP and Desktop INP separately.

What is the difference between INP and FID?

FID only measures the input delay of the very first interaction on the page. INP, in contrast, considers all relevant interactions during a visit and measures Input Delay, Processing Time, and Presentation Delay. This allows INP to better represent and assess perceived responsiveness.

What is a good INP-Wert?

A good INP value is ≤ 200 ms, measured at the 75th percentile (P75) of your field data. Values between > 200 and ≤ 500 ms are considered in need of improvement, while > 500 ms is poor and requires urgent action.

How can you handle third-party scripts without losing tracking?

Use tag budgets and consent gates. Load third-party scripts asynchronously and, if possible, only after the first visible feedback or user interaction. Keep critical journeys clear and reduce the load with sampling or batching if necessary.

Which issues negatively affect INP?

INP suffers most when the main thread is overloaded. This can be caused by too many synchronous JavaScripts, long tasks (> 50 ms), or heavy event handlers. Also critical are numerous unbatched DOM changes, a lack of immediate visual feedback, and third-party scripts in the above-the-fold content.

What measures can you take to improve INP?

Improve your INP value by shortening the three measured time periods. A proven approach is to unload the main thread (reduce long tasks, split JavaScript) and minimize third-party scripts. Keep event handlers lean, move computational work to Web Workers, and process data asynchronously.

References

Splitt, M. (2023, May 10). INP in den Core Web Vitals. Google Search Central Blog. URL: https://developers.google.com/search/blog/2023/05/introducing-inp?hl=de

Wagner, J., & Pollard, B. (2025, September 2). Interaction to Next Paint (INP). web.dev (Chrome for Developers). URL: https://web.dev/articles/inp?hl=de

Shellhammer, A., & Neel, J. (2016, September 8). The need for mobile speed. Google Ad Manager Blog. URL: https://blog.google/products/admanager/the-need-for-mobile-speed/

European Parliament & Council of the European Union. (2016, April 27). Regulation (EU) 2016/679 on the protection of natural persons with regard to the processing of personal data… (General Data Protection Regulation, GDPR). Official Journal of the European Union, L 119, 1–88 (published May 4, 2016). URL: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng

Google Chrome Developers. (o. J.). Chrome UX Report (CrUX) API – Dokumentation. Chrome for Developers. URL: https://developer.chrome.com/docs/crux/api?hl=de

World Wide Web Consortium (W3C). (o. J.). Event Timing. W3C Working Draft. URL: https://www.w3.org/TR/event-timing/