Radimir Bitsov
October 12, 2018
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.
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 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.
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.
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.
First Interactive and Consistently Interactive, later known as First Idle and Time to Interactive, are defined and calculated as follows:
These metrics help us to accurately calculate when an application is ready for interaction, and will likely respond in timely manner.
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! 👏
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.
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!
Radimir Bitsov
Radimir is a Frontend engineer at Project A Services. Find him on Twitter.
Join thousands of subscribers keeping up-to-date with web performance news and advice.
Addy Osmani
Engineering Manager at Google Chrome