What is TTI? #
The TTI metric measures the time from when the page starts loading to when its main sub-resources have loaded and it is capable of reliably responding to user input quickly.
To calculate TTI based on a performance trace of a web page, follow these steps:
- Start at First Contentful Paint (FCP).
- Search forward in time for a quiet window of at least five seconds, where quiet window is defined as: no long tasks and no more than two in-flight network GET requests.
- Search backwards for the last long task before the quiet window, stopping at FCP if no long tasks are found.
- TTI is the end time of the last long task before the quiet window (or the same value as FCP if no long tasks are found).
The following diagram should help visualize the steps above:
Historically, developers have optimized pages for fast render times, sometimes at the expense of TTI.
When users try to interact with a page that looks interactive but actually isn't, they'll likely respond in one of two ways:
- In the best-case scenario, they'll be annoyed that the page is slow to respond.
- In the worst-case scenario, they'll assume the page is broken and likely leave. They may even lose confidence or trust in the value of your brand.
To avoid this problem, make every effort to minimize the difference between FCP and TTI. And in cases were a noticeable difference does exist, make it clear through visual indicators that the components on your page are not yet interactive.
How to measure TTI #
Lab tools #
What is a good TTI score? #
To provide a good user experience, sites should strive to have a Time to Interactive of less than 5 seconds when tested on average mobile hardware.
For details on how your page's TTI affects your Lighthouse performance score, see How Lighthouse determines your TTI score.
How to improve TTI #
To learn how to improve TTI for a specific site, you can run a Lighthouse performance audit and pay attention to any specific opportunities the audit suggests.
To learn how to improve TTI in general (for any site), refer to the following performance guides:
- Preconnect to required origins
- Preload key requests
- Reduce the impact of third-party code
- Minimize critical request depth
- Minimize main thread work
- Keep request counts low and transfer sizes small