Time To Interactive Explained: How to Measure Your Site’s TTI

When web developers audit a webpage’s load time, they don’t just look at the time it takes to load the full page. They look at a series of milestones from the time the page starts loading to when it finishes. These milestones provide important signals about the way the page loads and the quality of the user experience. 

One of the most important milestones is interactivity. If a page has loaded enough that a user can interact with its elements (such as clicking links or highlighting text), then a user can be more patient waiting for the rest of the page to load, since they can already begin using it. This milestone is known as Time to Interactive, or TTI. 

What is Time to Interactive?

Time to Interactive is a metric Google devised as part of their Lighthouse scoring framework to measure the time it takes for a webpage to be fully interactive to users. Google defines “fully interactive” using three criteria:

• The page displays any content (either images or text). Using First Contentful Paint (FCP), this measures the time it takes for any content to render on a page. The entire page does not need to load to count as interactive. 
• The page registers event handlers for most visible elements. An event handler is a piece of code, typically a JavaScript-based code, that listens for events (pre-specified actions that users take). For example, an event could be a form submission. Once the form loads and the JavaScript is ready to listen for the form submission, you have a registered event handler.
• The page responds to user interactions within 50 milliseconds. Users can interact with links, buttons, and other clickable elements.

A page that meets these criteria is fully interactive. And the time the page takes to get from First Contentful Paint to a fully interactive state is its TTI. Note that this time will be shorter than the time it takes to fully load the page.

Although TTI was originally part of Lighthouse’s scoring framework, Google removed it in 2019. This was partially due to redundancies between TTI and Total Blocking Time (TBT) and First Input Delay (FID), which also measure the time it takes for a web page to become interactive, and partially due to Google stating that TTI was “overly sensitive to outlier network requests.”

Time to Interactive vs. Total Blocking Time

TTI measures the overall time it takes for the page to be fully interactive, whereas TBT measures how long individual elements block the page from being interactive. Google chose to remove TTI and keep TBT as part of its scoring framework, because the latter is more granular. 

Often, TTI and TBT can be the same, but they can differ depending on the nature of what’s blocking the page from being interactive. If a site has one large piece of code that needs to load before the page is interactive, the two metrics will likely be the same. However, if a second site has a series of small pieces of code that need to load, equal in size to the large piece of code on site on the first site, the second site will perform better on TBT but the same on TTI. In the latter case, the site will feel more usable faster, which is why Google considers TBT to be more reflective of a user’s web experience.

Despite Google removing TTI from Lighthouse in favor of TBT, it’s still a useful metric for diagnosing why your web page feels slow to become interactive. Improving your TTI is very likely to help improve your site’s overall performance scores, even if it’s not a direct part of the score’s calculation anymore.

How Time to Interactive fits into site and server speed

One more important thing to keep in mind is that TTI is only as good as your site and server speeds. This means that you’ll need to keep a close eye on both your First Contentful Paint and your Time to First Byte (TTFB) metrics. We’ve already touched on FCP, which can generally be thought of as site speed. But you can use TTFB to measure server speed, since it refers to the time it takes for the server hosting a website to respond to a customer’s browser. 

Taking a closer look at these metrics, Google defines a good FCP score as being 1.8 seconds or less. And they define a good TTFB score as 800 milliseconds or less. By ensuring that you’re hitting these benchmarks, you’ll boost your TTI score as a result. 

How to measure TTI

Google has removed TTI from the current Lighthouse scoring framework, and most other web performance tools have followed suit and replaced it on their tests. However, if you’re a web developer, you can still access the source code for Time to Interactive from Google and create your own program to test it.

Alternatively, you can use Google’s free PageSpeed Insights or Lighthouse performance audit tools to check your Total Blocking Time. TBT aligns closely with TTI, and the insights that these tools provide for improving TBT will likely improve your TTI as well.

Lastly, GTMetrix, a tool that measures website performance, still provides TTI in its website performance testing tool, making it the simplest way for marketers to access their TTI score. Note that while GTMetrix calculates TTI scores in the same way that Google did, its framework for analyzing performance is slightly different.

Factors that increase Time to Interactive

According to Google, website owners should set a goal to keep TTI within the green range, which is 3.8 seconds or less. If your website has a TTI of above this threshold, at least one of the following factors may be at play:

• Bulky JavaScript practices: Large JavaScript bundles take time to download, parse, and compile. Browsers need to complete these long tasks before the page can be interactive.
• High number of requests: When the browser needs to fetch lots of assets from different places, it slows down your TTI. Requests can be for CSS scripts, fonts, and large images.
• Server issues: The wrong server can slow down your TTI. The most common example of this is a lack of HTTP/2 server optimization, which allows the server to process multiple requests at the same time.
• Interruptions to idle periods: TTI measures when the browser goes “idle” (isn’t busy loading main thread resources) for five seconds or longer. But if the browser isn’t allowed to go idle, the TTI will get delayed. This often occurs with third-party scripts such as support chat widgets that frequently require the main thread to run code on the page.
• Over-prioritizing visibility: Sometimes, web developers heavily prioritize loading the most visible page elements but deprioritize elements critical to interacting with the page, such as JavaScript code that listens for page clicks. This leads to a user experience where the page is visible, but users aren’t able to click on the actual links.
• Custom builds: While building your own site from scratch can have its benefits, doing so can also introduce risk to your site speed, security, and more. Third-party apps and plugins with little governance may not be optimized for performance or SEO, and they might be missing long-term dev support. These could have a major negative impact on your site’s ability to keep up with user requests. 

We recently did an in-depth analysis of site and server speed on Shopify storefronts, and as part of this effort we built a tool that lets you conduct a Site Speed Audit for your own site. Check it out and see how your site speed stacks up.

How to improve TTI

The best way to improve your TTI will depend on what is slowing your time down. There are many possible factors, but there are two main techniques to address them:

 JavaScript execution optimization

Break your largest JavaScript code files into smaller, more easily executable files, minimize the use of third-party JS files, reduce unused scripts, and minify or compress your files.

Resource/request priority management

By default, a browser needs to understand what code is and isn’t necessary to make a page interactive. Websites can streamline this by reducing the number of requests a page needs (e.g., images, CSS files, and scripts), preloading the most important requests, and using resource hints like dns-prefetch to help the browser manage critical requests.

Server cost reduction 

Although managing server infrastructure may not have direct impacts on your TTI, it can absolutely impact your bottom line. Especially if you pour endless resources into making sure it responds to requests quickly. One way you can reduce these costs is by moving to a platform like Shopify, because our global server network takes on all that work so you don’t have to—and keeps your sites responsive by default. 

Boost your Time to Interactive—and overall speed—with Shopify

An interactive site is key to long-term business success. And at Shopify, we’re committed to helping you achieve that success both now and in the long run.

Storefronts built on Shopify are the fastest in the world, rendering up to 2.4x faster than stores on other platforms. What’s more, because of our industry-best infrastructure, 93% of businesses on Shopify have a fast store, which is more than any other major commerce platform. 

With Shopify, you won’t just get a better TTI score. You’ll boost site and server performance. And as a result, you’ll make your customers—and your bottom line—a whole lot happier.