This article is part of my personal wiki where I write personal notes while I am learning new technologies. You are welcome to use it for your own learning!
The RAIL model is a user-centric way to measure the performance of your websites. It is based on how users perceive your application delays:
- People are great at tracking motion and dislike when animations aren’t smooth. Smooth animations require the famous 60 frames per second which leaves 16ms to render a frame (6ms for the browser to paint the new frame on the screen, 10ms for your app to produce the frame)
- The attention span of a user is limited. Under 100ms he user will perceive something as being immediate, any longer and the user will be able to perceive a delay. 100-300ms and the user will perceive a small delay. 300-1000ms and things will still feel part of continuum. Beyond 1 second a user will lose focus and beyond 10 seconds the user gets frustrated and is likely to abandon the task at hand, your web app and never come back (:D).
RAIL focuses on 4 points of interaction between a user and your app:
- Response: Respond in under 100ms
- Animation: Produce a frame in 10ms
- Idle: Maximize idel time
- Load: Deliver content in under 1000ms
The analysis on user perception reveals that you need to respond to use input in under 100 ms before they notice a lag. This applies to most points of interaction between a user and your web app: clicking a button, checkbox, form input, triggering an animation, etc. For actions that take longer to complete, you’ll need to provide some sort of immediate feedback to the user so he/she knows that his request is being processed.
Written by Jaime González García , Dad, Husband, Front-end software engineer, UX designer, amateur pixel artist, tinkerer and master of the arcane arts. You should follow him on Twitter where he shares useful stuff! (and is funny too).Follow @vintharas