RAIL is a user-centric performance model that breaks down the user\u2019s web experience into four key actions. It encourages developers to think holistically about web performance and rather than ask \u201cwhat does slow mean?\u201d instead ask \u201cwhat does the user feel when they\u2019re interacting with the things we build?\u201d<\/p>\n
In this post, we\u2019ll explore what RAIL is, the guidelines the model sets out to help you determine when you\u2019ve \u201cdone enough,\u201d and tools you can use to measure RAIL on your website.<\/p>\n
What is the RAIL Model?<\/h2>\n
When a web page is loading, there\u2019s a whole lot of technical stuff going on behind the scenes<\/a>. On the backend, the site is requesting and receiving files and resources, while on the front-end the browser is loading words, images and other media.<\/p>\n While all this is happening, the user is waiting for the page to load so he or she can start interacting with it, which is all well and good if you\u2019ve optimized your page speed. The problem is, developers often forget about what happens after<\/i> a page has loaded.<\/p>\n According to Google\u2019s Web Fundamentals Guide<\/a>, users spend the majority of their time waiting for sites to respond to their inputs (i.e. clicks, taps and toggles), not waiting for sites to load. So while your site might load lightning fast, it means diddly-squat if a user then clicks a link in your navigation and it takes two seconds for the input to register.<\/p>\n The RAIL model takes this into account, breaking down the user\u2019s experience with a website into four key actions: response<\/b>, animation<\/b>, idle<\/b>, and load<\/b>.<\/p>\n Each RAIL action comes with its own performance goals, which are based on human perception thresholds, which we\u2019ll cover shortly. The idea behind the model is that if you optimize your site based on each of these areas and provide a consistently fast web experience, then your users will be happy.<\/p>\n Before we dig into the specifics of RAIL and the benchmarks it sets, it\u2019s important to first understand human perception thresholds.<\/p>\n When you\u2019re optimizing your site to make it faster, do you think about how a user might feel<\/i> while they\u2019re browsing your site? Probably not. Yet, this perceived notion of your site\u2019s performance is a critical part of RAIL.<\/p>\n Jakob Nielsen\u2019s work on response times<\/a> has been the go-to academic research for human perceptions of web performance since it was published in 1993. In 2015, when Googlers Paul Irish and Paul Lewis proposed their RAIL model, they revised Nielsen\u2019s original findings, adding in an extra response time (0 to 16ms) for animations.<\/p>\n These perception thresholds are useful to keep in mind since they provide a handy guideline for how long your site should take to respond to various user interactions.<\/p>\n It\u2019s important to keep in mind, however, that how<\/i> users perceive performance delays often depends on network conditions and the device they are using. For example, it wouldn\u2019t be out of the question to expect a page to load in less than 1 second on a powerful desktop machine over a fast wi-fi connection, but for mobile devices using slow 3G connections, loading in 5 seconds is more realistic. As such, mobile users are generally more patient.<\/p>\n For more on human perception thresholds, check out What is Perceived Performance and Why You Need to Optimize It<\/a>.<\/p>\n The great thing about RAIL for developers is that it provides a structure for thinking about web performance, but also sets benchmarks we can aim for when building and optimizing websites.<\/p>\n Let\u2019s look at each of the four key areas of RAIL in more details.<\/p>\n Response relates to how fast your site responds to a user interaction. For example, this might be a clicking, toggling form controls, or starting an animation. It\u2019s crucial your site responds immediately before there\u2019s any noticeable lag. Otherwise, the connection between action and reaction will be broken.<\/p>\n As Lewis describes<\/a>, if you\u2019ve ever clicked on something and it took so long to respond that you started wondering whether it registered your click, so you clicked a second time, but in doing so you interrupted the response to your first click\u2026 Well, this is exactly the kind of thing RAIL aims to avoid.<\/p>\n Goal:<\/b> Process events in under 50ms.<\/p>\n Google\u2019s guidelines<\/b>: Sites should process user actions\/inputs within 50ms to ensure a visible response within 100ms. For actions that take longer than 50ms to complete, always provide feedback, i.e. display a loading indicator or change the color for the active state.<\/p>\n Animations have become so ubiquitous in web design that users expect very smooth interactions and notice immediately when the frame rate is even slightly off.<\/p>\n Animations include:<\/p>\n Goal<\/b>: Produce a frame in 10ms.<\/p>\n Google\u2019s guidelines<\/b>: To animate properly, each frame of an animation should be completed in less than 16ms in order to achieve 60 frames per second (i.e. 1 second \u00f7 60 = 16.6ms). The maximum \u201cbudget\u201d for each frame is 16ms, but browsers need about 6ms to render each frame.<\/p>\n Idle time refers to what is happening behind the scenes of your site after it has initially loaded. As I mentioned in a recent post about\u00a0prebrowsing techniques<\/a>, idle time provides an ideal opportunity for preloading, prefetching, and preconnecting resources.<\/p>\n Goal<\/b>: Maximize idle time to increase the odds that the page can respond to a user interaction within 50ms.<\/p>\n Google\u2019s guidelines<\/b>: Only load the most critical elements of your page during the initial load, and use idle time for everything else. Google recommends grouping any deferred work during idle time in 50ms blocks so your site can respond within the 100 response window. If a user interacts with a page during idle time work, their interaction should take priority and interrupt the idle time work.<\/p>\n Load refers to getting the user to the first meaningful paint quickly. This means loading pages in less than 1 second.<\/p>\n The faster your pages load, the less like users will bounce\u2014and the less likely they will lose focus and perceive a task they are trying to complete as broken. It\u2019s no surprise that, according to Google<\/a>, sites that load quickly have longer average sessions, lower bounce rates, and higher ad viewability.<\/p>\n Goal<\/b>: Deliver first meaningful paint in 1 second and achieve time to interactive<\/a> in under 5 seconds.<\/p>\n Google\u2019s guidelines<\/b>: Optimize your page speed relative to the devices and network connections your users use to access your site. Focus on optimizing the critical rendering path<\/a> for your site to unblock rendering and use idle time to your advantage. Google recommends pages should load and be interactive in 5 seconds or less on mid-range mobile devices using slow 3G connections. For subsequent loads, aim for 2 seconds or less.<\/p>\n![\"RAIL](\"https:\/\/wp-rocket.me\/wp-content\/uploads\/1\/rail-performance-model.jpg\")
<\/a>Image:<\/i> Paul Irish<\/i><\/a>.<\/i><\/p>\nTime and Perceived Performance<\/h2>\n
\n
The RAIL Model\u2019s Performance Benchmarks<\/h2>\n
Response<\/h3>\n
Animation<\/h3>\n
\n
Idle<\/h3>\n
Load<\/h3>\n