Time to Interactive: Focusing on the Human-Centric Metrics

Time is perceived subjectively by all of us therefore, optimizing for what directly affects this perception should be an essential part of every performance strategy – always prioritize the user experience.

Today I'd like to introduce you to Time to Interactive – a performance metric that focuses on what users see and experience.

The problem with web performance metrics

How can metrics give us an understanding of what users actually experience?

Historically, page load time was used as an indicator of performance, but ultimately it did not in any way describe a user experience other than the page had fully loaded.

There is a trend of people recommending and using paint based metrics as part of their web performance analysis. First Paint and First Meaningful Paint are very useful indicators because they describe key moments of our content rendering.

Page load time and paint based metrics do not tell us enough.

The exciting new Long Tasks API gives us the ability to detect JavaScript tasks (function calls, event handlers, user input events) on the main thread that exceed 50ms of duration. This number hasn’t been selected randomly. Studies show that it takes only 100ms before users notice delay following an interaction. ⏳

Time to Interactive

Time to Interactive is a performance metric that highlights the moment when the JavaScript main thread is idle for a number of seconds. The motivation behind it is to measure how efficient a site or application is when interacted with. As it relies on the main thread, it is heavily dependent on both the amount of JavaScript as well as the CPU speed of a given device.

You’ve likely once tapped on a link, at the moment when the browser decided to render more content, change the font or some other jarring moment. Suddenly, without any other input from your side, you’ve been relocated to a different section on the page or even another website. Frustrating, right? The reason behind this behavior is a non-interactive moment when the browser’s main thread is blocked. 🙈

For a better understanding of this metric, it's valuable to explain first what is the main thread and then why it can be locked.

JavaScript main thread

Despite your powerful computer or brand new phone with multiple CPU cores, JavaScript still operates in a single-threaded environment.

The main thread can be visualized as a pipeline that handles JavaScript execution, matching the required CSS rules and also calculates the layout of each element. Finally, it’s responsible for drawing and composing the page.

Seeing as all user interface interactions and updates are managed in this single-threaded environment, the main thread becomes blocked when a single long-running operation prevents the completion of the next process in the pipeline.

Locking the main thread

Building complex web applications with a lot of JavaScript code can sometimes cost us more than initially meets the eye. Addy Osmani explained in great detail within his article "The Cost of JavaScript". He noted that one of the heaviest costs for the JS engine after downloading the JavaScript code is to parse/compile it.

Parsing and compilation processes add new tasks to the JavaScript event loop part of the main thread. As you’ll recall, any tasks that exceed 50ms are considered long tasks. During this period of time, users won’t be able to receive any immediate feedback from their actions which will result in the frustrating situation explained earlier.

Subtly blocking the main thread is far more destructive on mobile devices. Tasks that take 50ms on a high powered desktop can take 3-5X longer on a phone. That results in lockups, poor animation, janky scrolling and battery drain.

These two aspects show how crucial for the user experience is to have long JavaScript tasks in the main thread. We can identify these problems in our web apps by continuously tracking the Time to Interactive metric.

How is Time to Interactive calculated?

First Interactive and Consistently Interactive, later known as First Idle and Time to Interactive, are defined and calculated as follows:

• First Idle is the first early sign of time where the main thread has come at rest and the browser has completed a First Meaningful Paint.
• Time to Interactive is after First Meaningful Paint. The browser’s main thread has been at rest for at least 5 seconds and there are no long tasks that will prevent immediate response to user input.

These metrics help us to accurately calculate when an application is ready for interaction, and will likely respond in timely manner.

Why does Time to Interactive matter?

Optimizing your web app or site with Time to Interactive in mind means better user experience since you’ll mitigate the risk of blocked UI elements.

In a recent case study about Pinterest’s Progressive Web App, the team observed 60% higher user engagement after reducing Time to Interactive from 23s to 5.6s, and to 3.9s on repeat visits! 👏

Measuring Time to Interactive

First Idle and Time to Interactive can be monitored using Calibre’s automated web performance tests.

WebPageTest shows when the main thread is responsive as part of the waterfall diagram.

Time to Interactive is also integrated into Lighthouse. You can run the performance audit report from your Chrome browser dev tools.

Conclusion

Time to interactive gives us valuable insight to people’s experience when using our web apps. The trend of creating more human-centric performance metrics is the right direction. It helps us to understand the importance of creating accessible and responsive products.

I hope you enjoyed this introduction. Let me know if you have any questions!

Learn more 🎓

• The Cost of JavaScript in 2018
• Can you afford it? Real-world web performance budgets
• Why Web Developers Need to Care about Interactivity
• Accurately measuring layout on the web
• Time To Interactive – Measuring more of the user experience
• First Interactive and Consistently Interactive

Radimir Bitsov

Radimir is a Frontend engineer at Project A Services. Find him on Twitter.