The quick download:
TTI shows how long users wait before your page really works. Learn what slows it down, how to test it, and the practical tweaks that make your site feel instantly responsive.
-
TTI shows when a page actually responds to clicks, taps, and scrolls, not just when it first paints.
-
High TTI is usually driven by long-running JavaScript, render‑blocking resources, and offscreen assets loading too early.
-
You can measure TTI in the lab with tools like Lighthouse, WebPageTest, and PageSpeed Insights before rolling out changes.
-
Techniques like code‑splitting, lazy loading, and deferring non‑critical scripts can cut TTI by seconds and lift both UX and SEO.
Time to Interactive (TTI)
Time to Interactive (TTI) is the moment your page stops pretending to be ready and actually is. It captures the transition from “I can see the page” to “I can use the page,” showing how long users wait before clicks, taps, and scrolls respond reliably. A strong TTI keeps that delay short, making your site feel fast, usable, and trustworthy.
In this guide, we break down what TTI measures, why it matters for user experience and Core Web Vitals, how to measure it accurately, and the most effective ways to bring your TTI scores down.
What is TTI?
TTI is a website performance metric that estimates the time it takes a web page to become fully interactive when a user loads it. Before this metric was introduced, web developers relied on standard performance metrics such as page load time and the Onload signal to gauge performance. However, the accuracy of these measures was poor when compared with what the user sees as a fully loaded page. TTI is a better alternative to those typical metrics for measuring effective page load time.
What Does TTI Measure?
We can call a web page ready for full interaction if it satisfies the following three criteria:
- The page shows useful content to the user.
- Event handlers are registered for the most visible elements.
- The response time for user interactions is a maximum of 50 milliseconds.
The first condition relies on the First Contentful Paint (FCP) metric, which estimates when the page first starts showing useful content, so a page reaches TTI only after it achieves FCP. Event handlers define the code to execute when an event occurs, such as when a user clicks a link or scrolls the page, and when they are registered correctly they can respond accurately to user interactions. The third condition matters because users expect a smooth experience with minimal response delays, and anything slower quickly becomes frustrating.
How TTI Affects the User Experience
Many teams optimize for page load speed without thinking about how quickly the page actually becomes usable. The result is a page that appears to load fast but still has a high TTI because it cannot respond to user input. Users see a “ready” page, start clicking or tapping, and nothing happens. That disconnect drives frustration, shows up as rage clicks, and ultimately pushes down conversions while pushing up bounce rates.
How TTI Affects SEO
Users will spend more time on a page with more interactive content, resulting in a lower bounce rate and more page visits. Having such positive SEO metrics affects the ranking of a website.
How TTI Relates to Other Core Web Vitals
How TTI Relates to FCP
As mentioned above, FCP measures the time from when the page starts loading to when it starts displaying content. TTI occurs after FCP, and there can be serious page-loading issues if the website has a large gap between FCP and TTI.
How TTI Relates to FID
First Input Delay (FID) measures the time a webpage takes to respond to a user’s very first interaction with it. Both TTI and FID are related to web page interactivity, and if a page is not fully interactive, it is not yet ready to respond to user input. If the TTI value is low, the page is more likely to have a good FID score.
How TTI Relates to TBT
Total Blocking Time (TBT) measures how long the main thread is too busy to respond to user input between FCP and TTI. When the main thread is tied up with long tasks, clicks, taps, and scrolls are effectively ignored until that work finishes. A high TBT score means users experience more “frozen” time, while reducing long tasks on the main thread lowers TBT and helps the page reach TTI sooner.
The Business Impact of TTI: A Case Study
Tokopedia is one of the largest e-commerce companies in Indonesia, with around 2.7 million merchants nationwide. Its website lists more than 18 million products and attracts over 50 million visitors each month. A Google case study reports that this performance-first approach helped Tokopedia achieve a 35% increase in click-through rates (CTR), an 8% increase in conversions (CVR), and a 4-second improvement in TTI.
To get there, the team first identified long-running JavaScript as the main source of performance issues and focused on reducing its impact. They built a controller library to load third-party JavaScript selectively and replaced heavy libraries with lighter alternatives. They also adopted code-splitting, adaptive loading, and lazy-loading strategies, and it deferred loading non-critical JavaScript.
These JavaScript and resource optimizations improved TTI by 4 seconds, resulting in a TTI value for the homepage of 2.2 seconds and TTI values for product pages of 1.9 seconds. They have been able to reduce app JavaScript code size in the home page by 88% and product page by 86%.

How to Measure TTI
What Is a Good TTI Score?
Generally, a good TTI score is under 3.8 seconds, which provides a great user experience and better SEO. The table below shows how the TTI value relates to a web page’s performance.
| TTI (seconds) | Interpretation |
|---|---|
| 0-3.8 | Fast |
| 3.9-7.3 | Moderate |
| Over 7.3 | Slow |
Measuring TTI Using WebPageTest
TTI is a metric measured in the lab rather than with real users. You can calculate TTI using lab tools like Google Chrome Lighthouse and WebPageTest.
The following example will show you how to measure TTI using WebPageTest (you can also run Lighthouse as an option, but we won’t do that in this example):
- Navigate to https://webpagetest.org/
- To get the TTI, you can select any test type from advanced testing, web vitals, or simple testing. We will select simple testing for our example.
- Enter the web page URL you want to test. (We used this URL.)
- Select the test configuration you want. Optionally, you can select the Run Lighthouse Audit option to perform a Lighthouse test as well.
- Start the test and wait a couple of minutes to get the final results.
Go to the performance test results page and click on the Export Files dropdown. In WebPageTest, TTI is a Page-level Interactivity Metric that you can find in the JSON data.

- You can either select View JSON to view the complete JSON directly in the browser or Download JSON to your machine.
- Search for interactive in the JSON file to get the TTI values in both milliseconds and seconds, along with the related score.
| Sample text: requests: cpu: 50m memory: 50Mi limits: cpu: 100m memory: 100Mi |

Additionally, click on Plot Full Results on the summary page to see statistical information on the TTI value.

- In our example, the TTI value is 2.8 s, the FCP value is just 0.486 s, and the TBT is less than or equal to 0.30 s. Those numbers mean that this page has good interactivity.
Using PageSpeed Insights
To measure TTI using the PageSpeed Insights tool, enter the website URL and click the Analyze button. As you can see in the image below, for our example page it has an overall score of 79 in core web vitals assessment done by PageSpeed Insights and the TTI value is 3.3 s, which is a good value meaning that our web page responds to user interactions quickly.

Factors that Contribute to Having Poor TTI
1. Long-Execution JavaScript Code
When a web page contains JavaScript code that takes a long time to execute, this directly affects the time to reach TTI. Longer JavaScript execution time is caused by unoptimized code, unused scripts, large third-party JavaScript bundles, coding errors, etc. Parsing, compiling, and executing such script files takes a significant amount of time, affecting the overall page load time.
You can find any performance bottlenecks by analyzing JavaScript execution on the page. The WebPageTest can indicate such longer execution loads. For example, the following images are screenshots from the web vitals for the page https://www.dailymirror.lk/, which you can find at this link. You can see that both TBT and the largest contentful paint of the page are higher than the standard values, and the long-running tasks on the page indicate the longer executing JavaScript.


It is necessary to minimize JavaScript parsing and compiling times to reduce the execution time. Usually, JavaScript code executes on the main thread, which gets blocked until the execution completes. Longer JavaScript files can consume a large amount of main-thread time, causing delays in the page and ultimately affecting TTI. You can reduce main-thread blocking time by reducing JavaScript execution time.
How to Fix the Problem
- Code-Splitting: Code-splitting can significantly reduce the impact of long-running JavaScript on page load speed. Instead of including all the JavaScript at once when loading the first page, split it into multiple bundles and load only the essential files as needed.
- Reducing the use of Third-Party JavaScript: A web page can have dependencies with too many external JavaScript libraries. Those third party scripts can be larger files that take a great deal of time to load. Reduce their use wherever possible and load them only when they are necessary for the page.
- Minifying the Code: JavaScript and CSS files can contain unnecessary characters like newlines and spaces, contributing to slower page loads. Code minification eliminates such useless elements and compresses the code.
2. Render-Blocking Resources
Render-blocking resources like JavaScript, CSS, and HTML imports significantly delay page rendering, pushing FCP and TTI further. These blocking resources are often unimportant files that you can load after the browser renders essential elements. Therefore, you can reduce page load time and improve TTI by eliminating render-blocking resources.
WebPageTest can identify render-blocking resources and highlight them with an orange cross. The screenshot below shows the waterfall view of the page https://www.dailymail.co.uk/news/index.html. It shows render-blocking resources highlighted with orange cross marks.

How to Fix the Problem
There are several ways to reduce render-blocking resources. The most effective is to defer loading blocking code until after the most critical parts of the page are rendered. To do this, you first need to profile your page to identify which resources are blocking rendering. You can then remove non-critical third-party JavaScript and CSS, load them later or conditionally, and minify remaining scripts and styles to further reduce their impact.
3. Offscreen Images
Hidden offscreen images get downloaded when the page loads but are not immediately visible to users. An example is an image that will be visible only if the user scrolls down through the page. Loading offscreen images can lead to the browser taking too much time to load content that users do not need initially, especially since image files are larger than text-based resources.
For example, the following images show the offscreen images downloaded for the page https://www.dailymirror.lk/ we used in our first example.

How to Fix the Problem
To reduce the impact of such images, you can lazy-load offscreen images, ensuring they are downloaded only when needed. The browser can then focus on displaying only the content required for the initial page load.
Wrap Up
Time to Interactive (TTI) is one of the clearest ways to understand how responsive your pages feel to real users. Teams that actively optimize for TTI see fewer rage clicks, better engagement, and stronger SEO. As we’ve seen, high TTI scores usually come from long-running or unoptimized JavaScript and other blocking resources, which tools like WebPageTest make straightforward to spot. By trimming JavaScript, deferring non-critical code, and optimizing other heavy assets, you can bring TTI down and make your site feel noticeably faster and more reliable.
Know when your pages are actually ready
A page that looks loaded but is not yet interactive frustrates users and raises bounce rates. LogicMonitor helps you track TTI and other performance metrics that reflect real user experience.
FAQs
How do I figure out which scripts or resources are slowing down my TTI?
Start by running lab tests in tools like Lighthouse or WebPageTest and look for long tasks on the main thread, large JavaScript bundles, and render‑blocking resources. Focus first on scripts that run before TTI and show up repeatedly as long tasks or orange “blocking” markers in your waterfalls.
My lab TTI looks fine, but users still complain the site feels slow. What should I check next?
Compare your lab results with field data from real users, paying attention to different devices, networks, and geographies. Often the issue is heavy JavaScript or third‑party code that only loads in production, or on slower mobile hardware, which you can uncover by profiling those real‑world scenarios.
What are the fastest changes I can make to improve TTI without a full redesign?
Prioritize deferring non‑critical JavaScript, lazy‑loading offscreen images, and trimming or replacing bulky third‑party libraries. These changes reduce main‑thread blocking and network overhead, so users can interact with key UI elements much sooner.
How often should I track TTI, and which other metrics should I watch with it?
Monitor TTI continuously alongside metrics like INP, LCP, and TBT so you can see both when the page becomes interactive and how it responds to ongoing input. Watching these together makes it easier to connect technical changes to real impacts on engagement, bounce rates, and conversions over time.





