What Is Time to Interactive (TTI)? Complete Guide (2026)

Saar TwitoPublished May 21, 2025Updated April 30, 20268 min read

Saar TwitoFounder & SEO Engineer

Hi, I'm Saar - a software engineer, SEO specialist, and lecturer who loves building tools and teaching tech.

What Is Time to Interactive?

Time to Interactive (TTI) measures the moment a page becomes reliably responsive to user input. The page has finished its visual content, the main thread has quieted down, and clicks, taps, and keystrokes will be handled within the perceptual budget. It's the metric behind every "the page looks done — why isn't my click registering?" experience.

Key Facts (TL;DR)

Good TTI: ≤ 3.8 seconds — the page is reliably responsive shortly after it paints.
Needs Improvement: 3.8 – 7.3 seconds — interactive elements visible but unresponsive for a noticeable stretch.
Poor: > 7.3 seconds — users assume the page is broken; rage-click and bounce rates climb.
Definition: TTI fires once the main thread has been quiet for 5 consecutive seconds (no long tasks > 50 ms) and there are no in-flight network requests, working backward from the last long task before that quiet window.
Deprecated as a score component: TTI was removed from the standard performance score formula in 2023 because Total Blocking Time (TBT) and Interaction to Next Paint (INP) capture the same problem more reliably. It is still surfaced as a diagnostic.
Still useful: Even though it doesn't feed the score, TTI is the cleanest single number for "is this page actually usable yet?" — useful for setting performance budgets and tracking regressions.
Business impact: Walmart engineering reported every 100 ms of front-end speed improvement increased conversion by 1%. Pages with TTI > 7s typically see double-digit drops in form completion.

Think of TTI as the green light at a restaurant. The plates are on the table (LCP), the menu is set (FCP), but the staff is still chasing back to the kitchen — and your wave goes unnoticed. TTI is the moment service finally settles and you can actually flag someone down.

Why TTI Still Matters in 2026

It's the cleanest "is the page usable?" signal.TBT and INP both capture main-thread blocking, but TTI gives you a single moment-in-time milestone that's easy to communicate, budget against, and track over time.
Diagnostic value for slow pages. When a page feels broken-after-paint, comparing FCP to TTI tells you exactly how long the unusable window lasted. That gap is where users abandon.
Indirect ranking impact.TTI itself isn't a Google ranking signal, but the same root causes (heavy JS bundles, blocking third-party scripts, slow hydration) drag down INP — which is a Core Web Vital. Fixing TTI fixes INP.
Conversion impact.Forms, checkouts, and signup flows live or die on TTI. A page that paints in 1.5 seconds but doesn't accept input until 8 seconds will lose users to misclicks and abandonment.
AI search visibility. Pages that score poorly on Core Web Vitals rank lower, and AI search systems (Google AI Overviews, Perplexity, ChatGPT) preferentially cite higher-ranked pages.

How TTI Is Calculated

TTI is the timestamp of the last long task on the main thread, provided that task is followed by a quiet window. The rules:

Walk forward from First Contentful Paint, looking for a 5-second window with no long tasks (a long task = any single main-thread task > 50 ms) and no more than 2 in-flight network requests.
The TTI timestamp is the end of the last long task before that quiet window starts.
If no such window exists in the recorded trace, TTI is undefined for the test.

Timeline of long tasks (each X is a > 50ms main-thread task):

  FCP   X  X    X  X X X         X        | (5 sec quiet)
  |__|__|__|____|__|_|_|_________|________________________
  0     1     2  3  4  5         6                       11
                                  ↑
                                  TTI = 6.0s
                                  (last long task before
                                   the 5-second quiet window)

Why "5 seconds of quiet"?

The 5-second window is a heuristic that empirically distinguishes "the page is done loading" from "the page is between bursts of work." Anything shorter produces too many false positives where TTI fires during a temporary lull and is then violated by another wave of long tasks. 5 seconds is the sweet spot for stability.

TTI vs TBT vs INP — Three Views of the Same Problem

All three metrics measure main-thread blocking, but at different abstractions. Understanding the relationship helps you pick the right one for the job.

Aspect	TTI	TBT	INP
What it captures	Moment the page becomes reliably responsive	Total blocking duration during load	Worst real-user input response (98th pct)
Measurement	Lab	Lab	Field (CrUX)
Good threshold	≤ 3.8 s	≤ 200 ms	≤ 200 ms
In performance score?	No (since 2023)	Yes (~30%)	No (separate ranking signal)
Used for ranking?	No	No	Yes (Core Web Vital)

Bottom line:Use TBT and INP for scoring and ranking. Use TTI as the single number you set performance budgets against — "our checkout page must be interactive in under 4 seconds on a mid-range mobile."

How to Check Your TTI Score

Greadme's deep scan — surfaces TTI as a diagnostic alongside the other Web Vitals and pairs each issue with an AI-generated fix or one-click GitHub PR. Recommended starting point.
Greadme's crawler scan — measures TTI across every indexable page so you can flag the templates with the longest unusable windows after paint.
Chrome DevTools → Performance tab — record a load locally; the "Long Tasks" lane and "Bottom-up" tab pinpoint which scripts are pushing TTI out.
Google Search Console → Core Web Vitals report — TTI itself isn't reported (no field equivalent), but URLs flagged for poor INP almost always have poor TTI too. Use INP issues as a proxy.
web.dev articles — Google's reference docs for Long Tasks API, the RAIL model, and INP migration are the primary sources for the techniques in this guide.

8 Proven Ways to Improve TTI

1. Cut JavaScript Bytes Aggressively

The dominant cause of slow TTI is too much JavaScript. Every kilobyte must be downloaded, parsed, compiled, and executed — all on the main thread. A 1 MB JS bundle on a mid-range Android phone routinely produces 1,500–3,000 ms of TTI delay.

Fix: Audit your bundle for unused libraries, replace heavy dependencies with lighter ones, and remove polyfills you no longer need.

2. Code-Split by Route and Component

Don't ship the JavaScript for the cart, the dashboard, and the admin panel on the homepage. Code splitting lets each route load only what it actually needs.

// Dynamic import: code is only fetched when the modal opens
const Modal = await import('./HeavyModal');

3. Defer or Async Non-Critical Scripts

A blocking <script> in the head pauses parsing and pushes TTI out. defer runs after document parsing; asyncruns whenever it's ready, in any order.

Fix: Default every third-party script to defer or async. Reserve synchronous loading for code that must run before paint.

4. Move Heavy Work to Web Workers

CPU-bound work (parsing large JSON, image processing, search indexing, encryption) should never run on the main thread. Web Workers run JavaScript on a separate thread, freeing the main thread to become interactive.

Fix:If a task takes > 100 ms and doesn't need DOM access, move it to a Worker.

5. Use Server-Side Rendering or Static Generation

Single-page apps that render entirely client-side push enormous amounts of work onto the main thread before the page becomes interactive. SSR or static generation hands the browser ready-to-paint HTML; JS only needs to attach event handlers.

Fix: Move to a framework that supports SSR or static export (Next.js, Nuxt, SvelteKit, Astro). Hydration cost is non-zero but typically 5–10× cheaper than client-side rendering from scratch.

6. Audit and Trim Third-Party Scripts

Tag managers, A/B testing tools, chat widgets, and ad scripts are TTI's favorite hiding place. Every third-party script runs on your main thread, and the page owner pays the cost.

Fix: Use one tag manager to consolidate scripts, then quarterly-audit every third-party tag. Anything not needed for the first 5 seconds should fire on requestIdleCallback.

7. Preconnect to Critical Origins

If your fonts, scripts, or APIs are served from a different origin, the browser pays a TLS handshake cost before it can fetch them. Preconnecting cuts that out of the critical path.

<link rel="preconnect" href="https://fonts.example.com">
<link rel="preconnect" href="https://api.example.com">

8. Set a JavaScript Performance Budget

The cheapest TTI to fix is the TTI that never regressed. Performance budgets enforce a hard cap on bundle size or main-thread time at build time.

Fix:Add a budget rule to your bundler config (e.g. fail the build if main bundle exceeds 200 KB gzipped). Track TTI in CI and fail PRs that regress it > 500 ms.

Common TTI Problems and Fixes

Problem: Heavy Hydration Payload

What's happening: A server-rendered SPA sends an 800 KB hydration data blob, and the framework parses + reconciles all of it on load.

Fix: Trim hydration data to only what the client actually consumes. Move read-only data into the rendered HTML; only ship interactive state through hydration.

Problem: Tag Manager Stack Adds 4 s to TTI

What's happening: Five+ third-party scripts (analytics, A/B test, heatmap, chat, ads) all loading synchronously on first paint.

Fix: Audit and remove duplicate analytics tools. Consolidate the rest behind one tag manager that defers loading. Anything not needed for the first 5 seconds should fire on requestIdleCallback.

Problem: Long-Running `useEffect` on Mount

What's happening: A React component runs an expensive synchronous calculation in useEffect(() => ..., []), blocking input for hundreds of milliseconds right after the page paints.

Fix: Move the work off the main thread (Web Worker), break it into yielding chunks, or compute it on the server and pass results as props.

Problem: TTI Undefined in Lab Tests

What's happening: The page has continuous network or main-thread activity (long-polling, persistent WebSocket, infinite scroll prefetch) that never produces a 5-second quiet window.

Fix: Throttle background activity that runs on first load. Long-polling, prefetch, and analytics flush should all fire after the first quiet window — not before it.

FAQ

What is a good TTI score?

A good TTI is 3.8 seconds or lesson a mid-range mobile device. Between 3.8s and 7.3s "needs improvement," and over 7.3s is poor — the threshold at which most users assume the page is broken.

Is TTI a Core Web Vital?

No. The Core Web Vitals are LCP, INP, and CLS. TTI is a lab-only diagnostic — it's computed during synthetic tests, not from real users, and Google does not use it as a ranking signal.

Why was TTI removed from the performance score?

In 2023, TTI was removed from the standard performance-score formula because Total Blocking Time (TBT) and Interaction to Next Paint (INP) capture the same problem more reliably and with lower variance. TTI is sensitive to small timing changes (a single late long task can shift it by seconds), which made it unstable for scoring. It remains in audits as a diagnostic.

What's the difference between TTI and Total Blocking Time?

TTI marks the moment the page becomes reliably responsive (one timestamp). TBT measures how much blocking happened during the run-up to TTI (a duration). A page can have a fast TTI of 4 seconds but a poor TBT of 800 ms if there were several long tasks in the load window.

Will fixing TTI improve INP automatically?

Almost always yes. Both metrics are caused by the same root problem — main-thread blocking. The 8 fixes above (cut JS, defer scripts, Web Workers, SSR, etc.) target both at once.

Why does my desktop TTI look fine but mobile is terrible?

Mobile CPUs are 4–10× slower than desktop CPUs at JavaScript execution. A 100 ms task on a high-end laptop becomes a 400–1,000 ms task on a mid-range Android phone. Always test TTI under simulated mobile conditions (4× CPU slowdown is the standard).

Does TTI affect SEO or AI search engines?

Indirectly. TTI itself isn't a Google ranking signal, but slow TTI almost always coincides with poor INP — which is a Core Web Vital ranking signal. Lower rankings reduce both organic visibility and AI-citation odds (since AI search systems preferentially cite higher-ranked pages).

Conclusion

TTI is the moment your page goes from "visually loaded" to "actually usable" — the gap between FCP/LCP and TTI is where users misclick, rage-click, and bounce. Even though it no longer feeds the performance score directly, TTI remains the cleanest single number for setting performance budgets and tracking regressions.

The fixes are the same ones that lift TBT and INP: ship less JavaScript, defer what you can, break up what you can't, and move heavy work off the main thread. Run a Greadme deep scan to see your TTI, identify which scripts are pushing it out, and get a prioritized fix list.