The RAIL model is a performance pattern. It breaks down the user experience into crucial indicators. The aim is to help to define performance goals.

RAIL stands for response, animation, idle, and load. These states represent the web app life cycle. The order might be misleading, but LIAR isn't a good acronym for a famous model or pattern.

Tldr;

This post shows you all you need to know about the RAIL model, what it defines, and its aim.

Users visit a website with unexpressed expectations. UX researchers measured the impact of perceived delay on the user's actions. UX researches point out that even a delay of milliseconds influences the user actions.

In the real world, there is no single user. There is no constant network conditions and device capabilities. To have reliable and trustworthy data, you need to measure your users' experience. I wrote a blog post about user-centric performance metrics - Lab vs. RUM data.

Response: Handle the response within 50ms

Complete any actions initiated by the user within 100ms. The user should feel the interaction is instantaneous. The 100ms goal is still in the range of a fast and instant response.

100ms is the time the whole task should take. The time you should aim is 50ms. This budget is necessary because, for any interaction, the browser has to do some extra work.

If your applications handle the user's interaction within the recommended 50ms, the browser can queue the user's input for up to 50ms.

source

It would be best if you processed the user input within 50ms to ensure that response is visible to the user under 100ms. These 50ms apply to inputs, button clicks, toggles, or animations.

• Any action that takes longer than 50ms to process provides feedback for the user.

Animation: Aim for smooth animations

The aim of visual smoothness is essential for a well-perceived performance to the user. Most of the devices refresh their screens 60 times a second. To run a smooth interaction, the RAIL model defines a goal to put up a new picture or frame every time the device refreshes the screen.

Each of those new frames has a budget of 16ms (1 second / 60 = 16.67). In the real world, the browser has to do some extra work. It takes 6 ms to render each frame. The guideline for the animation is to aim for 10 ms per frame.

Idle: Maximize the idle time

Idle time is essential for the performance of your website. A high idle time increases the chance for the page to respond within the 50ms window.

During the idle time, you can complete deferred work. You can load resources after the initial page load or schedule analytics events. The task during an idle time should not extend 50ms to prevent the user from noticing the delay.

Load: Load the initial page fast and rest later

Loading a page fast will focus the user's attention. The user won't perceive the task as broken.

Optimize for a fast initial page load is significantly essential. Get as many assets out of the critical rendering path. Load resources depending on the network conditions and device capabilities.

A good goal is to have the website ready for interaction in five seconds or less for mid-range mobile devices with a slow 3G connection. For repeated visits, your goal should be 2 seconds to finish loading.

To achieve this goal, you should use the adaptive loading pattern. Adaptive loading is a pattern where your website responds to the user based on their actual device and network connection and eliminate all render-blocking resources.

Conclusion

In this post, I showed you the RAIL model. You should now know this performance pattern and its critical parts.

If you like this article, smile for a moment, share it, follow me, check out my RSS feed, and subscribe to my newsletter.

Cheers Marc