Time to Interactive (TTI)

Time to Interactive measures how long the page takes, from the start of the load, to reliably answer a tap or a click.

You won't find it in a Lighthouse report. Version 10 removed TTI from the report and from the performance score on 9 February 2023. The audit still runs and the value is still in the JSON, but it isn't produced the way the documentation says it is.

What TTI measures

The published algorithm has four steps:

1. Start at FCPTime until the browser paints the first text or image..
2. Search forward for a five-second window with no long task, and no more than two network GET requests in flight.
3. Walk back to the end of the last long task before that window.
4. That point is TTI. If there's no long task, TTI is FCP.

A long task is main-thread work of 50 ms or more. The two constants sit at the top of Lighthouse's interactive.js: a 5,000 ms quiet window, two allowed concurrent requests.

The idea is sound. A page can paint its buttons and then ignore you for four seconds, and TTI is the metric that catches the gap.

Is TTI still in Lighthouse?

The audit is still there. It's just hidden. In default-config.js, under a comment that reads "These are our 'invisible' metrics. Not displayed, but still in the LHR", sits this line:

{id: 'interactive', weight: 0, group: 'hidden', acronym: 'TTI'},

The 10 percent that TTI used to carry went to CLSHow much the page jumps around as it loads. Lower is better; 0 is rock-steady., which moved from 15 to 25 percent. The release notes for 10.0.0 put it plainly: TTI "no longer contributes to the performance score and is not displayed in the report. However, it is still accessible in the Lighthouse result."

So audits.interactive comes back on every run, with a value and with a score. The scoring curve is unchanged:

• Mobile: 3,785 ms scores 90. 7,300 ms scores 50.
• Desktop: 2,468 ms scores 90. 4,500 ms scores 50.

Both of those scores are then multiplied by zero.

The number is not the quiet-window number

web.dev documents that algorithm in full. Under Lighthouse's default settings, it never runs. None of the three pages I checked says so — not web.dev itself, not Chrome's own Lighthouse docs, not DebugBear.

The default is throttlingMethod: 'simulate', set in constants.js, and the quiet-window search belongs to the observed path. Lighthouse asks Lantern instead, and Lantern answers with a different formula:

TTI is the later of the LCP estimate and the end of the last long task in the simulation.

One consequence falls straight out of that: TTI can never come back lower than LCPTime until the largest thing in view (hero image, headline) has painted.. Lantern's Interactive.compute() ends by taking a Math.max against the LCP result.

We ran en.wikipedia.org/wiki/Lighthouse five times on one laptop, on Lighthouse 12.8.2, with the mobile profile our workers use:

Four of the five runs land within 9 ms of LCP. Run 2 matches it exactly. Five runs of vercel.com on the same laptop spread wider: 20 ms to 1,917 ms above LCP. Not one of the ten runs came back below it.

None of this is a bug. It's what a simulated metric can honestly tell you. But "the page went quiet for five seconds" is the wrong mental model for the number in front of you.

Why did Lighthouse drop it?

Google's stated reason is variability. The Lighthouse 10 post calls TTI "overly sensitive to outlier network requests and long tasks". The team's own performance FAQ said the same thing two major versions earlier. TBTHow long the main thread was busy and couldn’t respond to taps or clicks. has "lower variability", and it is "a stronger metric for evaluating the health of your main thread". Variability is also why two Lighthouse runs disagree more on some metrics than others.

The part that surprised me is that TTI never left the score. It went underneath it. TBT carries the largest single weight, 30 percent, and TBT is defined as the blocking time between FCP and TTI. Under simulation, Lantern's TBT throws an error if you hand it no interactive result. The metric that replaced TTI can't be computed without it.

The comment at the top of Lighthouse's TBT source says the quiet part out loud:

This is a new metric designed to accompany Time to Interactive. TTI is strict and does not reflect incremental improvements to the site performance unless the improvement concerns the last long task.

That is the case against TTI in two sentences. Shorten a long task in the middle of the load and TTI stays where it was. TBT drops with it, as long as the task stays over 50 ms.

What to read instead

• For how fast the page looks done, read LCP.
• For how much the main thread costs you during load, read TBT.
• For how the page answers a real person, read INPHow long the page takes to visibly respond to a tap, click or key press.. You need field data for that, and no lab tool can give it to you.

What we report

Every Lightscore report shows TTI in the metrics table, graded against 3,800 ms and 7,300 ms — Lighthouse's own mobile control points, with the first rounded up from 3,785. We keep the row because the value is in the JSON we hand you, and because it bounds the metric that does carry weight. Read it as context for TBT, not as a score.

There are two caveats. First, the value is the median run, not the median TTI. We pick the middle run by performance score, and TTI's weight in that score is zero, so a noisy TTI passes through unsmoothed. Second, our workers load the page with nobody in front of it. That's the same reason we can't give you INP.

The full Lighthouse JSON comes back with every report. TTI is at audits.interactive. The Main-thread workTotal time the browser’s single UI thread spent parsing, compiling and running code. work breakdown and the long-task list sit in the same file, and those are the two that tell you what to change.