Time to Interactive (TTI)
The old lab timestamp for when a page was not just visible, but quiet enough to keep answering input without long stalls.
See it
What it is
Time to Interactive was a lab metric for the point when a page had painted content and could keep responding promptly. Its measurement looked for a five-second quiet window after First Contentful Paint with no long tasks and no more than two in-flight network requests. That made it a useful shorthand for pages that looked finished while JavaScript boot work still monopolized the main thread.
Reach for TTI when reading an older Lighthouse report or investigating a heavy app shell, hydration, or startup sequence. Pair it with the network waterfall and long-task track so the result names the work that delayed reliable input instead of stopping at one timestamp.
Gotcha: Lighthouse removed TTI in version 10. It is not a Core Web Vital and it does not describe how real interactions behave across a visit. Use INP for field responsiveness and Total Blocking Time for a repeatable modern lab proxy; keep TTI for historical comparison and boot-sequence diagnosis.
Ask AI for it
Build a Time to Interactive diagnostic for this page from a Chrome DevTools Performance recording of the production build with a cold cache and fixed throttling. Mark First Contentful Paint, every main thread task over 50ms, and the count of in-flight network requests. Find the first five-second window after FCP with no long tasks and no more than two in-flight requests, then scan backward from that window to the end of the last long task, stopping at FCP, to calculate the legacy TTI value. Name the scripts and requests that postpone it. Also report Total Blocking Time and a real Interaction to Next Paint measurement, and label TTI as a legacy Lighthouse metric rather than a Core Web Vital.