Welcome back, performance enthusiasts! In our previous blog post, we delved into the world of TTFB (Time to First Byte) and explored strategies to optimize it. Today, we'll shift our focus to another crucial metric: TTI (Time to Interactive). TTI is arguably one of the most important metrics, as it directly correlates to user experience.
.gif)
So, what exactly is TTI? In simple terms, TTI measures the time from when a page starts loading to when all its resources have loaded, and it can reliably respond to user input quickly. It's the moment when users can actually start interacting with the page, whether it's scrolling up and down or clicking buttons.
As you might have guessed, TTI is influenced by TTFB, which we covered in our previous post. However, the real challenge with TTI lies in how quickly the web page can be rendered. And by rendered, we mean the HTML, styling, and JavaScript being executed to a level where the user can effectively use the webpage.
Measuring TTI is a bit more complex compared to TTFB. It starts with the FCP (First Contentful Paint), which we'll cover in the next chapter, and ends after the "long tasks" have finished. Long tasks are those that take comparatively more time to complete than others, such as fetching and executing JavaScript code or applying styling elements.
The order in which the client browser loads the page plays a significant role in TTI. Modern web frameworks often prioritize fast rendering, which can sometimes lead to higher TTI times. You might have encountered websites where everything looks fully rendered, but when you try to click a button, nothing happens. This happens when the main thread is blocked or the JavaScript code controlling those elements hasn't loaded yet.
To prevent this, developers can configure the website to disable buttons and provide clear visual indicators that the button is inactive until the necessary JavaScript has loaded.
It's worth noting that TTI is an older metric and should be measured in a controlled lab environment. Measuring TTI in the field is not recommended, as user interactions can introduce significant variance in your reports. The metric to use in the field is INP (Interaction to Next Paint).
Now that we have a high-level understanding of TTI and its influencing factors, let's explore what we can do to improve it. The general rule is to reduce the size, number, and execution time of JavaScript to the minimum possible.
Here are some actions you can take:
- Minify JavaScript: Remove unnecessary characters like whitespace and comments from your JavaScript code without changing its functionality. This reduces the overall size of the code.
- Preload important requests: Identify assets that are critical for your website, such as stylesheets, images, and JavaScript files. Add the preload key to download them as soon as possible, ensuring they're ready when needed.
For example, if you know that style.css and script.js are essential for your website, you can add them as preload links in the HTML:
<head>
<link rel="preload" href="styles.css" as="style" />
</head>- Reduce the number of third-party scripts: Third-party scripts are often the main culprit behind slow and unresponsive websites. Tracking user activity or loading customer support widgets can block the main thread and hinder interactivity.
At zeroteam.dev, we've helped numerous companies identify potential bottlenecks and solve them using Cloudflare. By implementing these strategies, you can significantly improve your website's TTI and provide a smoother user experience.
Stay tuned for our next chapter, where we'll dive into FCP and explore its impact on website performance.
Happy optimizing!