Time to Interactive (TTI) was a Lighthouse metric intended to identify when a page displayed useful content and then remained reliably responsive. It is no longer shown in the current Lighthouse HTML report and has no weight in the Lighthouse performance score. Lighthouse can still retain the hidden, zero-weight legacy value in its JSON output for compatibility.
Chrome began deprecating TTI in Lighthouse 8 and removed it from Lighthouse 10. The metric was too sensitive to outlier network requests and long tasks, which made it unstable and difficult to optimize consistently. Teams maintaining old dashboards should keep TTI for historical context, not treat it as a current optimization target.
What TTI used to measure
The former Lighthouse algorithm looked for a point after useful content appeared when the main thread and network then remained quiet enough for a defined window. The intent was to detect the “looks ready but does not respond” experience common in JavaScript-heavy applications.
That idea was useful, but the timestamp combined several concerns: content rendering, network activity, main-thread work, and a quiet-window heuristic. A late request or isolated task could move TTI even when the page's important interactions were unaffected.
Old reports may still contain TTI values generated by an earlier Lighthouse version or another tool. Always record the tool and version because the value is not directly comparable with a current Lighthouse score.
Why Lighthouse removed TTI
The Lighthouse team cited sensitivity to outlier network requests and long tasks. A quiet-window metric can wait for work unrelated to the user's main task, while a brief timing change can produce a disproportionately different result.
Removing TTI also simplified the performance score. Its remaining score weight was transferred to CLS in Lighthouse 10. The current documented score uses FCP, Speed Index, LCP, TBT, and CLS; TTI has no score weight.
Do not follow guidance that promises to improve a current PageSpeed score by lowering TTI. If a tool still displays it, check whether it is exposing Lighthouse's hidden legacy JSON value, using an old Lighthouse version, or presenting a separate proprietary metric.
What replaced TTI
There is no single one-for-one replacement. Use measurements that isolate the question:
- INP measures real interaction responsiveness in the field and is a Core Web Vital.
- TBT measures potential main-thread blocking during a Lighthouse load.
- LCP measures when the main content renders.
- FCP measures when the first qualifying content appears.
- a Performance trace identifies the network requests, long tasks, rendering work, and interactions responsible for a delay.
The current Core Web Vitals are LCP, INP, and CLS. TBT remains valuable in lab diagnosis but is not a Core Web Vital.
Migrate an old TTI report
Do not delete historical TTI records if they are useful for release analysis. Instead:
- mark the last Lighthouse version and date that generated the series;
- stop extending that series with values from a different algorithm;
- add a visible deprecation note to dashboards and documentation;
- establish separate baselines for field INP and lab TBT;
- preserve LCP, CLS, FCP, and Speed Index history where definitions remain comparable;
- update alerts so they do not page a team for a retired metric.
A monitoring migration should avoid splicing TTI, TBT, and INP into one chart. They have different units, observation windows, and meanings.
Diagnose loading responsiveness with TBT
Use Lighthouse TBT when the lab page appears but startup JavaScript may keep the main thread busy. Open a DevTools Performance trace, identify tasks longer than 50 milliseconds, and attribute them to their script and feature owner.
Typical interventions include route-level code splitting, removing unused dependencies, delaying nonessential third-party code, reducing hydration work, and breaking necessary computation into smaller tasks. The TBT guide gives a trace-led workflow.
TBT only covers the Lighthouse loading interval. A low value does not prove that a later filter, menu, editor, or checkout interaction is responsive.
Diagnose real interactions with INP
INP observes click, tap, and keyboard interactions during real page visits and reports a high-percentile interaction latency for each page load. Google classifies 200 milliseconds or less as good, more than 200 through 500 milliseconds as needing improvement, and more than 500 milliseconds as poor at the 75th percentile.
Break a slow interaction into:
- input delay, while earlier work occupies the main thread;
- processing duration, while event callbacks run;
- presentation delay, while the browser renders the next frame.
Real User Monitoring can capture the affected interaction and page state. Reproduce it in DevTools, then optimize the specific phase. A generic reduction in bundle size may help, but it is not a substitute for tracing the interaction.
Keep loading and responsiveness separate
A page can render its hero quickly and still respond poorly. It can also have significant startup work but provide fast interactions after load. Report loading, responsiveness, and stability independently so one score does not conceal another problem.
For loading, inspect the LCP phase breakdown. For visual progress, use FCP and Speed Index. For real responsiveness, use field INP. For lab main-thread pressure, use TBT. For movement, use CLS.
This separation creates clearer engineering work: the backend team can own TTFB, a media pipeline can own responsive images, and a feature team can own an expensive interaction.
Modernize performance budgets
Replace a TTI budget with a small set of explicit controls:
- field LCP, INP, and CLS targets at the 75th percentile;
- repeatable mobile Lighthouse baselines for TBT and visual metrics;
- route-specific JavaScript and image transfer budgets;
- maximum long-task policies for startup and critical interactions;
- release annotations and regression thresholds based on repeated runs.
Monitor comparable page types in IndieTools Speed, but retain the test configuration and release context. A metric migration is successful when the new measurements map more directly to the user experience and to an owner who can act on the result.
TTI remains useful vocabulary for understanding older audits. For current optimization, use the metrics and traces that replaced its broad heuristic rather than attempting to restore it to a modern Lighthouse report.
