Understanding INP vs. TTI in Modern Web Performance: Why They’re Not the Same Game
In the world of frontend performance metrics, it’s easy to get lost in the sea of acronyms. Two that often cause confusion—especially in Single Page Applications (SPAs)—are TTI (Time to Interactive) and INP (Interaction to Next Paint).
They may seem similar on the surface, but they actually serve different purposes and measure different aspects of user experience. In this article, we’ll break down what each metric truly measures, when and why they matter, and how to optimize for them in modern web apps like those built with React, Vue, or Hono.
TTI: It’s About Readiness
TTI (Time to Interactive) answers a basic but critical question:
How soon after page load can a user reliably interact with the app?
It measures the time from the moment the page begins loading to when the main thread has been idle long enough that input handlers can execute without major delay.
In other words, TTI is about initial hydration, particularly in server-rendered or static sites that hydrate client-side code. It tells you whether your app is “ready” to be used. For example:
- Has JavaScript finished parsing?
- Have key UI components mounted?
- Is the thread free of long tasks that block input handling?
If your page loads quickly but the main thread is still busy running scripts, it can feel slow to the user—even if everything looks like it's in place. That’s where TTI comes into play.
INP: It’s About Real-World Interactions
Now here’s the twist.
INP (Interaction to Next Paint) is not about the page becoming interactive. It’s about how your page stays responsive after it’s interactive.
INP observes user input during the page’s lifecycle and captures the worst interaction latency. It focuses on:
- When a user clicks, taps, or presses a key
- How long the app takes to respond visually
- Whether that response is delayed due to JavaScript, layout shifts, or paint operations
If a user clicks a button and sees a UI change within 50ms, that’s great. If another click results in a 300ms delay before anything changes on screen—that’s what INP flags.
Key Differences: TTI vs. INP
| Aspect | TTI | INP |
|---|---|---|
| Focus | Initial interactivity | Ongoing user interaction responsiveness |
| Triggers | Page load and JavaScript parsing | Actual user input (click, keypress, tap) |
| When It Happens | During page load | Throughout the entire session |
| Use Case | SSR hydration, script prioritization | UI latency, animation jank, blocking handlers |
| Interaction Requirement | No | Yes |
| Visual Feedback Required? | No | Yes — must result in next paint |
Common Misunderstanding: Route Changes and INP
A common question is:
“If my app changes route after an interaction, will it be measured by INP?”
The answer is no, not directly.
INP only tracks interactions that result in paint. If your route change (e.g., using React Router) immediately triggers a visual update after a user clicks a button or link, then that part can be counted. But if the interaction results in a full page change or navigation where the rendering happens on the next page (e.g., Next.js or SPA with delayed rendering), that won’t be captured as part of INP.
In short, navigational interactions are not measured unless they produce in-situ visual changes that are part of the interaction response itself.
So Where Does the Code Live?
It’s often said that if an interaction impacts UI, it lives in the client. That’s true. INP is a client-side metric, and it applies to any JavaScript code that handles events and modifies the DOM.
If your button click:
- Sends a network request, then updates UI
- Shows a modal or spinner
- Expands an accordion
- Plays an animation
Then INP tracks the delay between input and next visual feedback. If you defer too much work using setTimeout, or block the thread with heavy logic, INP will suffer.
Optimization Tips for Better INP
- Debounce smartly, but avoid unnecessary delays in paint
- Move non-critical logic outside the interaction frame (e.g., defer analytics, logging)
- Break large tasks using
requestIdleCallback,requestAnimationFrame, or chunking - Minimize layout thrashing and expensive reflows
- Avoid synchronous blocking operations in event handlers
- Optimize third-party scripts, especially if they intercept user input
Other Considerations
- INP is a field metric, meaning it's measured from real users in the wild, not in lab tests.
- TTI is mostly a lab metric, so it helps in development but doesn’t reflect real user frustration after the app becomes “interactive.”
- Browsers like Chrome use Interaction Observer (and eventually Event Timing API) to measure INP. So make sure your app renders meaningfully and fast on actual user devices—not just your high-end MacBook.
Finally
Understanding INP and TTI is crucial for modern web developers. You can't optimize what you don't measure—and these two metrics highlight two different bottlenecks:
- TTI tells you when your app is ready to be used.
- INP tells you whether your app actually feels good to use.
They’re both essential. But if you're already loading things fast and hydrating early, the next step is ensuring your app responds smoothly to every tap, click, and keystroke.
That’s what users care about—and what INP is built to measure.
Comments ()