Chapter 5:
Time to Interactive
December 28, 2021
12 min read
TTI is an important metric that helps determine the responsiveness of a web page. Sometimes a web page looks as if it were fully loaded, but users cannot interact with it yet in real time. A web page with a good TTI score increases page usability by becoming interactive more quickly, so users have a better experience.
This article explains TTI in detail, answering important questions about it, including how to improve TTI scores.
TTI is a website performance metric that estimates the time a web page takes to become fully interactive when a user loads it. Before this metric was introduced, web developers relied on typical performance metrics like page load time and the Onload signal to measure 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.
We can call a web page ready for full interaction if it satisfies the following three criteria:
The first criterion here uses the First Contentful Paint (FCP) metric, which estimates when the web page starts to show useful content; it means that a web page reaches TTI after achieving FCP. Event handlers define the code to execute when an event triggers, such as when a user clicks on a link, scrolls through the page, etc. Event handlers can respond accurately to user interactions when properly registered. The third criterion is critical because users require a good experience with minimal response delays to avoid frustration.
Sometimes web developers focus on optimizing web page load speed without thinking much about the impact on user interactivity. This may result in a page that loads quickly but has a higher TTI value due to the optimized load speed. Users see that the web page is ready, but it is still not usable because they cannot interact with it. This can lead to frustration that may manifest as “rage clicks,” in turn leading to poor user conversion and a higher bounce rate.
Users will spend more time on a web page that has more interactive content for them, resulting in a lower bounce rate and more page visits. Having such positive SEO metrics affects the ranking of a website.
As mentioned above, FCP measures the time from when the page starts to load to when it starts to display the content. TTI is reached after FCP, and there can be serious page loading issues if the website has a huge gap between FCP and TTI.
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 the web page is not fully interactive, it is not yet ready to respond to user inputs. If the TTI value is low, there is a higher chance of the page having a good FID score.
Total Blocking Time (TBT) estimates the time gap between FCP and TTI where the main thread is blocked. If the main thread gets blocked for a long time, it cannot respond to user interactions until it finishes its tasks. TBT helps measure the severity of non-interactivity of a page. The page can reach TTI faster if the main thread is freed from running long tasks.
Tokopedia is one of the largest e-commerce companies in Indonesia, consisting of around 2.7 million merchant networks nationwide. Its website has over 18 million product listings and receives over 50 million visitors monthly. A case study done by Google claims that Tokopedia’s performance-first culture has enabled it to achieve a 35% increase in click-through rates (CTR), an 8% increase in conversions (CVR), and a 4-second improvement in TTI.
To accomplish this, the company first identified that long-running JavaScript was the common reason for performance issues and took several steps to mitigate that problem. It built a controller library to load third-party JavaScript selectively and started using lighter libraries instead of heavier ones. It also implemented 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%.
Generally, a good TTI score is under 3.8 seconds, which provides a great user experience and better SEO. The following table shows how the TTI value corresponds to the performance of a web page.
TTI is a metric that is measured in the lab rather than using 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):
In our example, the TTI value is 2.8 s., the FCP value is just 0.486 seconds, and the TBT is less than or equal to 0.30 seconds. Those numbers mean that this page has good interactivity. You can find the test results of the above test conducted on WebPage Test in this link.
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.
Google PageSpeedInsight Tools Core Web Vitals Assessment results for the example page
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 take a large amount of main thread time, causing delays in the page and ultimately affecting TTI. You can reduce the main-thread blocking time if you reduce the JavaScript execution time.
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.
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.
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.
Render-blocking resources like JavaScript, CSS, and HTML imports block page rendering significantly, delaying FCP and TTI. These blocking resources are often unimportant files that you can load after the browser renders essential elements. Therefore, you can decrease page load time and improve the TTI value by eliminating those render-blocking resources.
WebPageTest can find such render-blocking resources and highlight them using an orange cross mark. For example, the following image shows the waterfall view of the page https://www.dailymail.co.uk/news/index.html which you can find in this link. It shows render-blocking resources highlighted with orange cross marks.
There are several ways to reduce blocking resources. The main solution is deferring the loading of blocking code until after the most critical components are loaded. This requires profiling your page to identify the blocking elements. Additionally, removing non-critical third-party JavaScript and CSS scripts and minifying the scripts can help mitigate this issue.
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.
To reduce the impact of such images, you can lazy-load offscreen images, ensuring that they will be downloaded only when needed. The browser can then work on only displaying the content that is required for the initial page load.
Time to Interactive (TTI) is an important and useful metric to estimate the responsiveness of a web page. Website owners should optimize web pages for lower TTI values because the TTI affects the user experience and SEO. As described in this article, there are several reasons for poor TTI, which you can identify using WebPageTest, and the main culprit is unoptimized JavaScript code. Optimizing JavaScript and other resources on the page can improve your TTI and, ultimately, its overall performance.