Guides

The 200 Milliseconds That Drive Users Out of SaaS

A SaaS interface feels slow long before it becomes measurable. Interaction to Next Paint measures this hesitation and determines ranking and user…

By Benedikt Langer July 17, 2026 4 min read

The 200 Milliseconds That Drive Users Out of SaaS

A SaaS interface feels slow long before it’s measurable. The user clicks. For a split second, nothing happens. It’s precisely this hesitation that Interaction to Next Paint measures. The value helps determine Google rankings – and even more importantly, whether an application feels responsive or sluggish.

Key Takeaways

INP has replaced FID. Since March 2024, Interaction to Next Paint has been a Core Web Vital. It measures delay across all interactions in a session – not just the first click. Target: under 200 milliseconds.
The main thread is the bottleneck. Poor INP scores almost always stem from JavaScript blocking the main thread. The interface can’t redraw until the task finishes.
SaaS suffers more than content pages. Interactive applications thrive on clicks, inputs, and state changes. Each interaction feeds into the INP score.

Why FID no longer cut it

First Input Delay only measured the delay of the very first interaction on a page. For traditional websites, that was a useful indicator. For a SaaS application where users click, filter, and type for minutes on end, it falls short. The first click tells you nothing about how the application feels after ten minutes of work.

Interaction to Next Paint closes that gap. It practically considers every interaction in a session and reports the worst representative value. That way, INP measures what users actually experience: responsiveness throughout the entire session. For interactive interfaces, it’s the more honest benchmark.

Where the milliseconds vanish

In nearly every case, the culprit is the main thread. The browser processes interactions, rendering, and JavaScript on the same strand. When a long task runs there, the response to the click has to wait. The user sees this as jank or a delay until something moves on screen.

In practice, there are three common patterns. Overly large JavaScript bundles that generate work during loading and every interaction. Expensive re-renders that force a click to recalculate an entire component hierarchy. And synchronous handlers that perform network or compute work before releasing the interface. If you want to improve INP, start here.

The most effective levers

The first lever is splitting. Long tasks can be broken into smaller chunks so the browser can respond to inputs in between. Modern approaches defer non-critical work behind the actual response – say, with a targeted yield to the scheduler. The user sees immediate feedback; the rest runs afterward.

The second lever is less code at the right time. Code-splitting loads only what the current screen needs. The third is rendering discipline: avoid unnecessary re-renders, memoize expensive calculations, virtualize large lists. No single trick delivers a breakthrough. The sum of these decisions determines whether an interaction stays under 200 milliseconds.

Real-world measurements

Lab tests in a developer’s browser are misleading. They run on fast hardware with a strong connection and rarely capture the interactions that hurt in daily use. Field data from real users is what counts. The Chrome UX Report delivers it in aggregated form; a custom collection via the Web Vitals library pinpoints exactly which interactions are driving poor scores.

The pragmatic approach: gather field data, identify the worst interactions, and optimise them directly. If you instead tinker blindly at supposedly slow spots, you waste time on symptoms nobody actually feels. INP isn’t just another SEO checkbox – it’s the metric that tells you whether your software feels good to use.

Frequently Asked Questions

What is Interaction to Next Paint (INP)?

INP is a Core Web Vital metric introduced by Google. It measures how quickly a website or application visibly responds to user interactions such as clicks, taps, and keyboard inputs. The score reflects the delay across the entire session, not just the first interaction. A good INP value is below 200 milliseconds.

When did INP replace the FID metric?

In March 2024, Interaction to Next Paint officially became a Core Web Vital, taking over from First Input Delay. While FID only measured the first interaction, INP evaluates responsiveness throughout the entire user session.

What INP value is considered good?

Google classifies an INP below 200 milliseconds as good, 200 to 500 milliseconds as needing improvement, and anything above 500 milliseconds as poor. The value is based on the 75th percentile of page loads.

Why are SaaS applications particularly affected?

Because they are highly interactive. Every click, keystroke, and state change contributes to the INP score. Content pages may have few interactions, but an application can rack up hundreds per session. A blocked main thread therefore has a much larger impact.

How can I measure INP reliably?

By collecting real-user field data, not lab tests. The Chrome UX Report provides aggregated values, while a custom implementation with the web-vitals library reveals which specific interactions are causing poor scores.