Paul Irish and Paul Lewis recent published an article introducing a new model for looking at performance. This model, labeled RAIL, is a user-centric approach to thinking about performance goals.

Why Another Model?

The main problem when talking about performance is that there are so many different ways of measuring it. Do we measure the initial load time, Speed Index, or time to first paint? There are several potential metrics, and everyone has their favorite.

Instead of focusing on just one performance metric, RAIL is an approach that takes into account the various contexts of user interaction on the site. For instance, when something is tapped, clicked, scrolled, or loaded. Since the user’s expectations will vary from context to context, each of these contexts have different performance goals.

Response, Animation, Idle, Load

RAIL stands for Response, Animation, Idle, Load—four distinct ways to categorize user actions. The premise of the model is that if we’re able to hit our targets in each or these areas, our users will be very happy with the website’s performance.

Here’s a brief overview of each area and its related performance goal.

  1. Response - This is how quickly there is a response when there is any input. For instance, when a user clicks or taps on a button or icon. The goal would be to provide feedback in less than 100ms, since that is the threshold where the response feels immediate.

  2. Animation - This would include visual animation, scrolling, and dragging. The goal would be to complete each frame within 16ms, since this would allow the animation to keep up with the ideal rate of 60fps,

  3. Idle - This entails work that is done in the background, especially work that is not needed at load. Ideally, the work would be grouped in to blocks less than 100ms—ideally 50ms or so—so that we would be able to keep our 100ms response goal if the user begins interacting with the page while other actions are being performed in the background.

  4. Load - This is how quickly we can get to the first meaningful paint—ideally under 1 second. Once the first paint is received, the goal is to keep the app responsive for the user.

A Helpful Approach

Instead of focusing on only one metric, approaching performance with RAIL in mind provides us a helpful reminder of the variety of things that will have an immediate impact of the experience of the user. We don’t want to have a quick loading page that then goes unresponsive. We also don’t want a responsive page that takes forever to load. Rather all of these aspects have an important place in the performance conversation, and RAIL reminds us of that.

For more information on this approach to performance, check out the links below.