What is the RAIL model in the field of web application performance evaluation

Measure performance with the RAIL model

RAIL is a user-centric performance model, which provides a structure to consider performance. This model breaks down the user experience into key operations (for example, click, scroll, load) and helps you define performance goals for each operation.

RAIL stands for four different aspects of the life cycle of a web application: response, animation, idle and loading, which is the abbreviation of response, animation, idle and load. Users have different performance expectations for each of these contexts, so performance goals are defined in terms of context and UX research on how users perceive latency.

Focus on the user

Let users become the focus of performance work. The following table describes the key indicators of how users perceive performance latency:

What users think about performance delays

• 0 to 16 milliseconds users are very good at tracking motion and don't like tracking when the animation is not smooth. As long as they render 60 new frames per second, they will think the animation is smooth. This is 16 milliseconds per frame, including the time required for the browser to draw a new frame to the screen, and it takes about 10 milliseconds for the application to generate a frame.
• 0 to 100 ms In response to user operations within this time window, users feel that the results are immediate. If this time delay is exceeded, the link between action and response is broken.
• 100 to 1000 ms in this window, things feel like part of the natural and continuous progress of the task. For most users on the web, loading pages or changing views is a task.
• 1000 milliseconds or more for more than 1000 milliseconds (1 second), users will lose their attention to the task they are performing.
• 10000 milliseconds or more and more than 10000 milliseconds (10 seconds), the user feels frustrated and may abandon the task. They may or may not come back in the future.

Goals and guidelines

In the context of RAIL, the terms goals and guidelines have specific meanings:

Goal: Key performance indicators related to user experience. For example, click to render in 100 milliseconds. Since human perception is relatively constant, these goals are unlikely to change anytime soon.

Guidelines: Suggestions to help you achieve your goals. These may be specific to current hardware and network connection conditions, and therefore may change over time.

Response: process events in under 50ms

Goal: Complete the conversion initiated by user input within 100 milliseconds, so that the user feels that the interaction is instantaneous.

Guidelines:

To ensure a visible response within 100 milliseconds, process user input events within 50 milliseconds. This applies to most inputs, such as clicking buttons, switching form controls, or starting animations. This does not apply to touch drag or scroll.

Although this sounds counterintuitive, responding to user input immediately is not always the right approach. You can use this 100 millisecond window to do other expensive work, but be careful not to block users. If possible, please work in the background.

For operations that take more than 50 milliseconds to complete, please always provide feedback.

50 ms or 100 ms?

The goal is to respond to input within 100 milliseconds, so why is our budget only 50 milliseconds? This is because in addition to input processing, there are usually other tasks to be done, and these tasks take up part of the available time for acceptable input responses. If the application performs work in the recommended 50 millisecond blocks during idle time, this means that if the input occurs during one of these work blocks, it can be queued for up to 50 milliseconds. With this in mind, it is safe to assume that only the remaining 50 milliseconds are available for actual input processing. The following figure shows this effect, which shows how input received during idle tasks is queued, thereby reducing the available processing time:

Animation: produce a frame in 10 ms

Target:

Generate every frame in the animation in 10 milliseconds or less. Technically speaking, the maximum budget per frame is 16 milliseconds (1000 milliseconds/60 frames per second≈16 milliseconds), but the browser needs about 6 milliseconds to render each frame, so the rule of 10 milliseconds per frame.

Aim for visual smoothness. The user will notice when the frame rate changes.

Guidelines:

In a high-pressure point like animation, the key is to do nothing where you can do it, and the absolute least where you can't do it. Use 100 millisecond responses as much as possible to pre-compute expensive work in order to maximize your chances of reaching 60 fps.

For various animation optimization strategies, see rendering performance .

Recognize all types of animation. Animation is more than just fancy UI effects. Each of these interactions is considered an animation:

• Visual animations, such as entry and exit, tweening and loading indicators.
• scroll. This includes flicking, that is, the user starts to scroll, then let go, and the page continues to scroll.
• Drag and drop operation. Animation usually follows user interaction, such as panning a map or pinching to zoom.

Idle: maximize idle time

Goal: Maximize idle time to increase the chance of a page responding to user input within 50 milliseconds.

Guidelines:

Use free time to complete deferred work. For example, for the initial page load, load as little data as possible, and then use idle time to load the rest of the data.

Perform work in an idle time of 50 milliseconds or less. If this continues, you may interfere with the application's ability to respond to user input within 50 milliseconds.

If the user interacts with the page during free time work, the user interaction should always have the highest priority and interrupt the free time work.

Load: deliver content and become interactive in under 5 seconds

When the page loads slowly, the user's attention will wander, and the user will think that the task is broken. Fast-loading sites have longer average sessions, lower bounce rates, and higher ad viewability.

Target:

Optimize the fast loading performance related to the user's equipment and network functions. Currently, a good goal for first loading is to load the page and interact in 5 seconds or less on mid-range mobile devices with slow 3G connections.

For subsequent loads, a good goal is to load the page within 2 seconds.

guide:

Test your load performance on mobile devices and network connections that are common among your users. You can use the Chrome User Experience Report to understand the distribution of your users’ connections. If the data does not apply to your site, Mobile Economy 2019 recommends a good global baseline for mid-range Android phones, such as Moto G4 and slow 3G networks (defined as 400 ms RTT and 400 kbps transmission speed). This combination is available on WebPageTest.

Keep in mind that although your typical mobile user’s device may claim that it is using a 2G, 3G, or 4G connection, in reality, due to packet loss and network differences, the effective connection speed is usually much slower.

Eliminate rendering blocking resources.

You don’t have to load everything in 5 seconds to have the feeling of a complete load. Consider lazy loading of images, code splitting JavaScript packages, and other optimizations suggested on web.dev.

Recognize the factors that affect page loading performance:

• Network speed and latency
• Hardware (for example, slower CPU)
• Cache eviction
• L2/L3 cache difference
• Parse JavaScript

Tools for measuring RAIL

There are some tools that can help you automate RAIL measurements. Which one you use depends on what type of information you need and what type of workflow you prefer.

Chrome DevTools

The following DevTools features are particularly relevant:

Restrict the CPU to simulate weaker devices

Limit the network to simulate a slower connection

View main thread activity to see every event that occurred on the main thread while recording

Use the Main section to view the activities that occur on the main thread of the page.

View the main thread activities in the table to sort the activities according to the activities that take the most time.

After recording the page, you don't need to rely only on the Main section to analyze the activity. DevTools also provides three table views for analyzing activities. Each view gives you a different view of the activity:

• If you want to see the root activity that caused the most work, use the Call Tree tab.
• If you want to view the activities that directly took the most time, use the Bottom-Up tab.
• If you want to view the activities in the order in which they occurred during the recording, use the Event Log tab.

Analyze frames per second (FPS) to measure whether your animation is really running smoothly

Use the performance monitor to monitor CPU usage, JS heap size, DOM nodes, layout per second, etc. in real time

Use the "Network" section to visualize network requests that occurred during recording

Capture screenshots during recording to accurately replay the appearance of the page when the page loads, or trigger animations, etc.

View the interaction to quickly identify what happens on the page after the user interacts with it

Use the interaction section to find and analyze user interactions that occurred during recording.

Find scrolling performance issues in real time by highlighting the page when the potential issue listener triggers.

View drawing events in real time to identify costly drawing events that may harm animation performance.

Lighthouse

Lighthouse can be used in Chrome DevTools, web.dev/measure, Chrome extensions, Node.js modules, and WebPageTest. You give it a URL, which simulates a mid-range device with a slower 3G connection, runs a series of audits on the page, and then gives you a load performance report and suggestions on how to improve it.

The following reviews are particularly relevant:

response

• Max Potential First Input Delay: Estimate the time required for your application to respond to user input based on the idle time of the main thread.
• Do not use passive listeners to improve scrolling performance.
• Total blocking time. Measure the total time the page was blocked from responding to user input (such as mouse clicks, screen clicks, or keyboard presses).
• Time To Interactive: Measure when users can interact with all page elements consistently.

Load

Do not register the service worker that controls the page and start_url. Service Workers can cache public resources on the user's device, thereby reducing the time it takes to obtain resources through the network.

Pages on the mobile web are not loading fast enough.

Eliminate rendering blocking resources.

Postpone offscreen images. Postpone loading offscreen images until they are needed.

Appropriately sized image. Don't provide images that are significantly larger than the size presented in the mobile viewport.

Avoid linking critical requests.

It does not use HTTP/2 for all its resources.

Efficiently encode images.

Enable text compression.

Avoid huge network load.

Avoid excessive DOM size. Reduce network bytes by transmitting only the DOM nodes needed to render the page.

Summarize

• Focus on the user.
• Respond to user input within 100 milliseconds.
• During animation or scrolling, a frame is generated within 10 milliseconds.
• Maximize the idle time of the main thread.
• Load interactive content in 5000 milliseconds.

More original articles by Jerry, all in: "Wang Zixi":