Time To Interactive (TTI) measures how long it takes a web page to become fully responsive to user input after it starts loading. It identifies the gap between when a page appears ready and when it actually responds to clicks and taps. For marketers, this metric reveals hidden friction that causes visitors to bounce before converting, even when the site looks fast.
What is Time To Interactive?
TTI is a lab-based performance metric that captures load responsiveness. A page reaches TTI when three conditions meet: the First Contentful Paint has occurred, event handlers are registered for most visible elements, and the page can respond to user interactions within 50 milliseconds (Chrome Developers).
Technically, TTI is calculated by finding a 5-second "quiet window" after First Contentful Paint where no long tasks block the main thread and no more than two network GET requests are in flight. The metric marks the end of the last long task before this quiet window begins. If no long tasks exist, TTI equals First Contentful Paint.
Why Time To Interactive matters
- Prevents rage clicks. Users expect buttons to work when they see them. When the main thread is blocked by JavaScript, clicks fail, causing frustration and immediate exit.
- Protects brand trust. Slow interaction response makes sites feel broken, damaging confidence in your brand value.
- Exposes SSR risks. Server-side rendering can make pages look interactive before client-side JavaScript hydrates the elements. TTI catches this "visual lie" where buttons appear clickable but do nothing.
- Mobile impact. The effect of delayed interactivity is more pronounced on mobile devices with limited processing power and network stability.
How Time To Interactive works
The calculation follows four steps:
- Start at First Contentful Paint. This establishes when useful content first appears.
- Find the quiet window. Search forward for a 5-second period with no long tasks and no more than two in-flight network GET requests.
- Locate the last long task. Search backward from the quiet window to find the final long task that ended before the idle period began.
- Mark the timestamp. TTI is the end time of that last long task, or First Contentful Paint if no long tasks exist.
A long task is any script execution that blocks the main thread for more than 50 milliseconds.
Time To Interactive and Lighthouse scoring
TTI was retired from the Lighthouse Performance Score in version 10.0.0. Previously, it accounted for 10% of the total score, but Google removed it because the metric was overly sensitive to outlier network requests and long tasks (Chrome Developers).
Despite its removal from scoring algorithms, TTI remains a valuable diagnostic tool. Sites performing in the 99th percentile render TTI in approximately 2.2 seconds (Chrome Developers). To provide a good user experience, sites should strive for a TTI of less than 5 seconds on average mobile hardware (web.dev).
Lighthouse displays TTI in three brackets (Chrome Developers):
| TTI (seconds) | Rating |
|---|---|
| 0–3.8 | Green (fast) |
| 3.9–7.3 | Orange (moderate) |
| Over 7.3 | Red (slow) |
Best practices
Defer non-critical JavaScript. Move scripts that don't affect the initial view to the bottom of the page or use the defer attribute. This prevents main thread blocking during the critical loading window.
Split your code. Break large JavaScript bundles into smaller chunks that load on demand. This reduces the initial payload that must parse and execute before interactivity.
Apply the PRPL pattern. Push critical resources, Render the initial route, Pre-cache remaining routes, and Lazy-load non-critical content. This structure prioritizes interactivity over total page load.
Audit third-party scripts. Analytics, ads, and widgets often cause long tasks. Remove unused tags or defer their initialization until after the page becomes interactive.
Initialize visible elements first. Instead of running all JavaScript on DOMContentLoaded, only initialize components currently in the viewport. Defer below-the-fold initialization until the user scrolls.
Preconnect to required origins. Establish early connections to third-party domains to reduce network latency for critical resources.
Common mistakes
Mistake: Optimizing for First Contentful Paint while ignoring TTI. Server-side rendering can make a page appear ready while JavaScript hydration blocks interaction.
Fix: Balance visual speed with JavaScript execution efficiency. Monitor both metrics together and ensure hydration does not lock the main thread for seconds after painting.
Mistake: Initializing all page components on load. Hidden forms, sliders, and widgets in modal windows often run scripts unnecessarily, consuming CPU time.
Fix: Implement lazy initialization. Only load JavaScript for elements the user can actually see and interact with immediately.
Mistake: Ignoring "No TTI" errors in testing. If CPU or network idle never occurs for 5 consecutive seconds, tools cannot calculate TTI.
Fix: Reduce background JavaScript activity and network requests that extend beyond the test cutoff period. Check for scripts that continuously poll or reload resources.
Mistake: Assuming TTI affects search rankings directly.
Fix: Use TTI to identify JavaScript bloat and main thread congestion, but focus public reporting on Core Web Vitals like Interaction to Next Paint (INP), which directly impact ranking signals.
Examples
Scenario: E-commerce checkout page.
A retailer loads heavy analytics and A/B testing scripts synchronously in the document head. The page paints in 1.2 seconds but freezes for 6 seconds while scripts initialize. Users click "Add to Cart" repeatedly with no response, then abandon. By deferring non-essential scripts and splitting the checkout bundle, TTI drops from 6.5 seconds to 2.1 seconds.
Scenario: Content site with server-side rendering.
A news site uses SSR for SEO. Articles appear instantly, but the hydration process locks the main thread for 4 seconds. Readers try to open navigation menus but nothing happens. Moving to progressive hydration and lazy-loading below-the-fold comments reduces TTI by 60%.
FAQ
What is Time To Interactive?
TTI measures the time from page load start until the page becomes reliably responsive to user input. It requires First Contentful Paint to complete, event handlers to register, and the ability to respond to interactions within 50 milliseconds.
How is TTI different from First Contentful Paint?
FCP measures when content first appears visually. TTI measures when that content actually responds to clicks and taps. A page can have fast FCP but slow TTI if JavaScript blocks the main thread after rendering.
Does TTI affect my Google rankings?
No. TTI is not a Core Web Vital and carries no direct ranking weight. However, the underlying issues that cause slow TTI (heavy JavaScript, main thread blocking) often hurt Interaction to Next Paint (INP), which is a Core Web Vital and ranking factor.
Why did Lighthouse remove TTI from the Performance Score?
TTI accounted for 10% of the score until Lighthouse v10.0.0. Google retired it because the metric was overly sensitive to outlier network requests and long tasks, making it unstable for scoring purposes (Chrome Developers).
What is a good TTI score?
Sites should aim for TTI under 5 seconds on average mobile hardware. In Lighthouse scoring, 0–3.8 seconds is considered fast (green), 3.9–7.3 seconds is moderate (orange), and over 7.3 seconds is slow (red) (Chrome Developers).
How do I measure TTI?
Run a Lighthouse performance audit in Chrome DevTools or use WebPageTest. For real-user monitoring, implement the Long Task API and calculate TTI based on the 5-second quiet window method described in Google's User-centric Performance Metrics documentation.
Can images affect TTI?
Images themselves do not block interactivity because they are not render-blocking. However, simultaneous image loading can keep network connections open, potentially extending the quiet window required to calculate TTI. Lazy loading images ensures they don't compete for bandwidth during the critical interactivity window.
