Enhancing Web Performance: Understanding TTI and RAIL Model
Written on
Chapter 1: Introduction to Web Performance Metrics
When optimizing websites, one may encounter a common pitfall known as "optimizing for metrics." These metrics do not truly encapsulate the user experience; rather, they should authentically reflect user interactions. This section will focus on TTI (Time to Interactive). Before diving deeper, it's essential to grasp some foundational concepts.
Section 1.1: Understanding the RAIL Model
RAIL is a performance model centered around the user experience. It breaks down a web application's lifecycle into four critical aspects, each influencing performance in unique ways:
- Response: The delay between user input (e.g., pressing a button) and the visual feedback should be under 100 milliseconds.
- Animation: Each frame's processing time (from JavaScript execution to rendering) should not exceed 16 milliseconds, ensuring smooth interactions like scrolling or dragging.
- Idle: JavaScript tasks on the main thread should be divided into segments, none longer than 50 milliseconds, even during periods of inactivity.
- Load: The webpage must be fully operational within 1000 milliseconds, allowing users to access essential content promptly.
For enhancing user experience, RAIL serves as an effective evaluation framework.
Section 1.2: Decoding TTI (Time to Interactive)
TTI indicates when an application has been visually rendered and is ready to respond to user actions. To comprehend TTI, we need to examine its calculation guidelines. According to official documentation, the first indication of TTI is marked by the "First Idle," which signifies that the main thread is idle and the browser has completed the "First Meaningful Paint" (FMP). TTI is achieved after FMP when the browser's main thread remains idle for at least five seconds, without any long tasks that might hinder immediate responses to user input.
In simpler terms:
- First Idle signifies that the main thread is stable and the FMP has occurred.
- TTI is reached post-FMP, where the main thread stays idle for a minimum of five seconds, free from any long tasks that could obstruct user interactions.
The first video titled "Regional Public Transportation Coordination Plan Performance Metrics from TTI 2018-2020" discusses performance metrics in public transportation systems and their implications on user experience.
Section 1.3: The Impact of Long Tasks
Long tasks are defined as any operation taking longer than 50 milliseconds, often resulting in noticeable lags or stutters for users. This delay is a significant contributor to a poor web experience.
To measure long tasks, you can use the following code snippet:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
console.log(entry);}
});
observer.observe({entryTypes: ['longtask']});
The output will provide valuable insights into long tasks and their durations.
Section 1.4: Calculating TTI
Before we calculate TTI, we must understand the Timing API. According to Google’s documentation, the "DOMContentLoadedEnd" event marks when all event listeners have finished executing. It's crucial to wait for this event to ensure the webpage is ready to handle user inputs.
The TTI can be approximated by the formula:
TTI = domContentLoadedEventEnd - navigationStart
Here, domContentLoadedEventEnd is the timestamp marking the end of the DOMContentLoaded event.
For those finding this calculation complex, Google offers a Polyfill to simplify the process.
The second video, "Visual Completion Measurement on Web" by Wooseok Jeong from Facebook, explores visual completion metrics and their relevance to web performance.
Like this article? Stay tuned for more insightful content and follow along!