Web performance RAIL model
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.
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 milliseconds influence the user actions.
|0 - 16ms||Users perceive an action or animation as smooth as 60 frames are rendered every second. That is 16 ms per frame.|
|0 – 100 ms||In this range, the user feels that the responses to his actions are instant.|
|100 – 300 ms||Users experience a small perceptible delay.|
|300 - 1000 ms||Actions feel slow, and the user recognizes that something has to be done (page load, etc.)|
|1000 ms - +||Users will likely have a mental context switch.|
|10 s - +||Users will leave.|
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, it means it the browser can queue the user’s input for up to 50ms.
But it would be best if you processed the user input within 50ms to ensure that response is visible to the user in 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.
In this post, I showed you the RAIL model. You should now know this performance pattern and its critical parts.