Time to Interactive (TTI)
Time to Interactive (TTI) measures how long it takes a page to become reliably interactive — visually rendered, with event handlers registered, and responding to input quickly. The definition looks back from a five-second quiet window (no long tasks, limited network requests) to the last long task before it. TTI is a lab metric from Lighthouse; web.dev now steers teams toward TBT and the field metric INP, since TTI is sensitive to single long tasks.
What this means
TTI is the point after which a page can be trusted to respond to user input promptly. It requires the page to have displayed content (past FCP), registered handlers for most visible elements, and to respond within 50ms of interactions.
The quiet-window rule
Lighthouse finds TTI by locating a five-second window with no long tasks and at most two in-flight network requests, then walking back to the end of the last long task before that window. That makes TTI deterministic in the lab but fragile: one stray long task can push it out dramatically.
- Requires render, handlers, and fast response
- Found via a five-second quiet window of no long tasks
- Lab metric — superseded in practice by TBT and INP
Why it misleads
Because a single long task moves TTI sharply, it is noisy and hard to act on directly. web.dev recommends optimising Total Blocking Time, which is more actionable, and validating responsiveness with field INP. Treat TTI as context, not a target in itself.
How it appears in analytics and logs
A late TTI means the page rendered before it could respond — heavy JavaScript kept the main thread busy past the visible paint, so taps in that gap would feel ignored.
Diagnostic use case
Use TTI in lab audits to estimate when a page stops looking interactive while actually being janky, but prefer TBT and field INP for diagnosing and confirming responsiveness.
What WebmasterID can help detect
WebmasterID classifies traffic first-party; TTI is a lab figure you can pair with field interaction timing observed against human-classified sessions.
Common mistakes
- Chasing TTI directly instead of the more actionable TBT.
- Treating a lab TTI as field responsiveness.
- Ignoring how one long task can swing the value.
Privacy and accuracy notes
TTI is a load-timing measurement, not an identifier. This material is educational, not legal advice.
Related pages
- Total Blocking Time (TBT)
Total Blocking Time (TBT) measures how long the main thread was blocked between First Contentful Paint and Time to Interactive. For each task longer than 50 milliseconds, the portion above 50ms counts as blocking time, and TBT is the sum of those portions. It is a lab metric — Lighthouse reports it — and web.dev treats it as a proxy for field responsiveness because high TBT usually predicts a poor Interaction to Next Paint.
- Interaction to Next Paint (INP)
Interaction to Next Paint (INP) measures a page's responsiveness by observing the latency of every click, tap, and key press during a visit and reporting a representative high value — close to the worst. Latency spans from the input to the next frame the browser paints. INP became a Core Web Vital in March 2024, replacing First Input Delay, because it captures the full processing-plus-render cost across all interactions, not just the delay of the first one.
- Speed Index
Speed Index measures how quickly the contents of a page are visibly populated during load. Instead of marking one moment, it records the visual completeness of the viewport frame by frame and integrates the un-painted area over time, so a page that fills in steadily scores better than one that snaps in late. It is a lab metric computed by Lighthouse from a video capture of the load, expressed in milliseconds where lower is faster.
- Website observability
Interactivity signals beside traffic.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.