Introducing RAIL: Site Performance Assessment Model

Recently published many tips to optimize the performance of sites. Phrases like “DOM is too slow” or “always use CSS animations” are good headlines, but the truth is different nuances.

We present an article by Paul Irish and Paul Lewis from the Google Chrome team about their website performance evaluation model. It can safely be called User-Centered Performance.
Take, for example, page load time, which is the most popular topic today. The problem is that someone uses a rather complicated formula for calculating the index of speed , someone measures by body.onload, someone by DOMContentLoaded or, possibly, by some other event.

None of us have infinite time that we could devote to optimizing the performance of the site, so we need to focus on some criteria: what is important for optimization and what is not. And we also need to agree on what the word "productive site" means for our users, because we make websites for them.

Many teams around the world worked on the concept of website performance, including the Ayri.rf team, and together we came up with a model that considers the user to be the center of this whole story with performance. This model was called RAIL = Response + Animation + Idle + Load.

What is RAIL in two words:

RAIL is a model in which user experience is broken down into several key actions. For example, click, dragging (movement with the mouse or touchpad pressed), scrolling, loading.
RAIL sets performance targets for these actions. For example, from a click to a drawing of actions on this click should take no more than 100 milliseconds.
RAIL provides a framework for planning performance improvement work. Designers and developers can identify and improve on those moments that can improve the most.

Before analyzing the RAIL model in detail, let's take another intermediate step and deal with one least favorite word of all: "slow."

"Slow"

What does “slow” mean? Change something in the DOM - slowly? What about the <script> tag in the <head> section? JavaScript animation is slower than CSS, right? If the operation takes 20 milliseconds, is it slow? And if 0.5 seconds? And if 10 seconds?

Although different operations require different times to be performed, it is difficult to objectively say how fast or slow it is. It is important to pay attention to the context in which this occurs.

For example, different parts of the code: one - working at the time when nothing happens on the screen, and the other at the time of the game cycle, when the player expects a certain reaction to his actions, will have different performance requirements. Users of your site or application will have different performance expectations for different contexts of their use.

As with any aspect of UX, the way users perceive it is paramount. The first "commandment" of work in Google sounds like "the interests of the user - first of all, and everything else will come."

Therefore, it is meaningless to assess whether an action is “slowly” performed. We need to find out “ what does the user feel when he interacts with something we have done?”

User at the heart of the concept of "performance"

Fortunately, there is a lot of research on how users perceive the response speed of sites and applications, for example, this is the work of Jacob Nielsen . Based on these results, we formulated for ourselves the following:

100 milliseconds : it is necessary to respond to the user's action during this time, and he will perceive that the reaction was immediate. Anything longer creates a delay between action and reaction.
1 second : that period of time during which the user feels the natural fulfillment of the “task”. A “task” can be, for example, loading a page or changing a list of products when changing a filter.
16 milliseconds : given that the screen is updated 60 times per second on most devices, during this time each next frame should appear on the screen (1000/60 = 16). People very well track the movement of their eyes, and anything slower than 60 frames per second violates their expectations.

These limits are very good because they set the foundation from which we can build.

Let's look at a typical example of user interaction:

In this short example there were several separate types of interaction:

Waiting for page load
View animation
Page scrolling
Clicking on the icon
View animated opening of the navigation unit
Waiting for page load
View animation
Page scrolling

If we mark up these types of interaction throughout the entire time segment of our video, we will get a picture of the following form:

In another video below we show examples of these types of user interaction.

We can break all types of user interaction into 4 types. Google calls these types of interactions RAIL, and each of these types of interactions has its own performance goals, which are based on the previously mentioned thresholds of human perception.

RAIL Performance Model

RAIL is an abbreviation for the English words response (response), animation (animation), idle (wait) and load (load). These four areas should be considered to discuss how to optimize the performance of sites and applications. If you optimize them based on the reaction time that users expect, they will be happy.

Response

When the user presses a button, it is necessary to “respond” to its action so quickly that he does not notice any lag. This applies to any user input element, no matter whether the user presses the switch in the form or the usual button. If the user doesn’t see the system’s response quickly, whether the switch is on or off, or the button press is animated, he will feel a gap between the action and the system’s response. Then he will have a feeling that the system is working with a delay.

The response is related not only to the software part of your site or application. This is entirely the delay that occurs between the user's finger touched the glass of the smartphone and the way the result of pressing it was drawn on the screen.

And here it is important to “calculate” not only the delay in your website or application, but also in the software and hardware of the smartphone, which is responsible for the recognition of clicks. Have you ever had such a thing that you press a button, but the delay is so great that you begin to doubt that the device in general “understood” that you pressed it? This is exactly the feeling that should not appear to the user.

Besides the fact that it is negative in itself, it also raises reasonable doubts as to how reliable the application with which it works, or how much the professional team has made the site. Similar doubts of the user will work against the image of your product.

The correct response occurs in less than 100 milliseconds after a user action.

Ideally, the response should immediately lead to the desired new state. If this cannot be done, you need to show the progress indicator to the user so that the user does not have the feeling that the device or application simply did not respond to pressing.

Animation (animation)

Animation is present in all kinds of modern applications. The animation means, of course, not “the drawn rabbit goes on the screen”, but such operations as scrolling, a side-scrolling menu and other similar effects related to the fact that the contents of the screen should change continuously for some time.

Animation can be divided by type:

Visual or ordinary : includes traditional animated screensavers, loading indicators, status indicators and the like, that is, what looks like a kind of animated fragment on the screen.
Scrolling animation : although it usually does not seem to be animation, technically it is. The user moves his finger across the screen or scrolls with a mouse or touchpad on a regular computer, and the image on the screen is constantly changing.

Drag animation: when the user uses some functions of the application or site, which implies that he clicks on an area on the screen and then “pulls” to the side in a depressed state. This may be a screen scaling, there may be “dragging” of objects and so on.

To make the animation look continuous, each frame of the animation must appear on the screen in less than 16 milliseconds , that is, at a speed of 60 FPS. (1 second / 60 frames = 16.6 milliseconds per frame).

Waiting (idle)

Within each application, there are many processes, but not all of them should work at such critical moments when the application is working out interaction with users of the "response" or "animation" type.

Initialization of various components, search and sorting of data, sending data to the analytics service: all this can be done while the application or browser is in standby mode.

To use the timeout correctly, you need to group tasks that are running at this time into blocks of no more than 50 milliseconds . Why is that? Because if the user starts the interaction, we want to have time to make a response in 100 milliseconds, and not to make him wait two seconds while the application does something and cannot respond to its actions.

Load

First of all, we want as soon as possible to show the user the first screen, on which, nevertheless, he should see enough useful information. Just showing him the cap of the menu and then waiting for the rest of the information to appear is no good. As soon as the first screen is shown to the user, the application or site should retain the ability to respond to the user's actions, even if the rest of the page is being loaded in the background. But the user should not even have problems with scrolling, clicking or animation even at this moment.

When we talk about “load fast”, we set a goal to show the first screen to the user in 1 second , otherwise he gets the feeling that the process is “interrupted”, he thinks that “it is slow,” and his attention may be distracted by something something else. He can switch from this site to another bookmark in the browser, and whether he will return and when is unknown.

To have time to show the page in 1 second, it is necessary to postpone all downloads of non-critical elements to the moments of waiting for user actions.

Results

In conclusion, we recall the performance goals of sites and applications in the concept of RAIL.

Response	Animation	Expectation	Loading
“Instant” response to user actions	The feeling of "inseparable" animation	Performing non-critical actions	Maintain response goals during page load
Interaction rendering in less than 100 milliseconds	Show each frame in less than 16 milliseconds	Complete each action in less than 50 milliseconds	Showing the first screen in 1 second

A few words about the measurements:

Measuring the speed of user interaction on a modern MacBook Pro (a very popular machine among designers and developers) is unlikely to be representative even for the average user, not to mention users with mobile devices.
Use a smartphone with average features.
Also test interoperability using “regular 3G” internet connection, without using advanced standards like LTE and without your very fast internet in the office.
Use site / application statistics to understand which devices your users are using. You can then simulate the work of the site / application on the vast majority of such devices.

I would also like to note the importance of responsible use of the device battery and memory. Perform all of the specified performance goals, but leaving the user with 10% of the battery charge and full memory - this is not "the interests of the user - first and foremost!"

So far we have not developed clear criteria for battery charge and memory usage, but perhaps in the future we will add B (for battery) and M (for memory) to the abbreviation, because these points cannot be ignored.

The importance of optimizing site performance is confirmed by a number of well-known cases: