Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Introducing RAIL: A User-Centric Model For Performance

There’s no shortage of performance advice, is there? The elephant in the room is the fact that it’s challenging to interpret: Everything comes with caveats and disclaimers, and sometimes one piece of advice can seem to actively contradict another. Phrases like “The DOM is slow” or “Always use CSS animations” make for great headlines, but the truth is often far more nuanced.

Take something like loading time, the most common performance topic by far. The problem with loading time is that some people measure Speed Index1, others go after first paint, and still others use body.onload, DOMContentLoaded or perhaps some other event. It’s rarely consistent. When it comes to other ways to measure performance, you’ve probably seen enough JavaScript benchmarks to last a lifetime. You may have also heard that 60 FPS matters. But when? All the time? Seems unrealistic.

Further Reading on SmashingMag:

Very few of us have unlimited time to throw at optimization work, far from it, and we need criteria that help us decide what’s important to optimize (and what’s not!). When all is said is done, we want and need clear guidance on what “performant” means to our users, because that’s who we’re building for.

On the Chrome team, we’ve been thinking about this, and we’ve come up with a model to put the user right back in the middle of the performance story. We call it the RAIL model.

If you want the TL;DR on RAIL to share with your team, here you go!

  • RAIL is a model7 for breaking down a user’s experience into key actions (for example, tap, drag, scroll, load).
  • RAIL provides performance goals8 for these actions (for example, tap to paint in under 100 milliseconds).
  • RAIL provides a structure for thinking about performance, so that designers and developers can reliably target the highest-impact work.

Before diving into what RAIL involves and how it could be helpful in your project, let’s step back and look at where it comes from. Let’s start with every performance-minded person’s least favorite word in the whole wide world: “slow.”

“Slow” Link

Is changing the DOM slow? What about loading a <script> in the <head>? JavaScript animations are slower than CSS ones, right? Also, does a 20-millisecond operation take too long? What about 0.5 seconds? 10 seconds?

What does slow mean?9
What does slow really mean?

While it’s true that different operations take different amounts of time to complete, it’s hard to say objectively whether something is slow or fast without the context of when it’s happening. For example, code running during idle time, in a touch handler or in the hot path of a game loop each has different performance requirements. Put another way, the people using your website or app have different performance expectations for each of those contexts. Like every aspect of UX, we build for our users, and what they perceive is what matters most. In fact, number one on Google’s ten things we know to be true10 is “Focus on the user and all else will follow.”

Asking “What does slow mean?,” then, is really the wrong question. Instead, we need to ask “What does the user feel when they’re interacting with the things we build?”

Putting The User In The Center Of Performance Link

Luckily for us, there’s long-standing academic HCI research on this topic, and you may have seen it before in Jakob Nielsen’s work on response time limits11. Based on those thresholds, and adding an extra one for animations (because it’s 2015 and we all love a bit of showbiz), we get the following:

  • 100 milliseconds
    Respond to a user action within this time window and they will feel like the result is immediate. Any longer and that connection between action and reaction breaks.
  • 1 second
    Within this window, things feel part of a natural and continuous progression of tasks. Beyond it, the user will lose focus on the task they were performing. For most users on the web, loading a page or changing views represents a task.
  • 16 milliseconds
    Given a screen that is updating 60 times per second, this window represents the time to get a single frame to the screen (Professor Math says 1000 ÷ 60 = ~16). People are exceptionally good at tracking motion, and they dislike it when their expectation of motion isn’t met, either through variable frame rates or periodic halting.

These perception thresholds are great because they give us the building blocks we need. What we need to do next is map them to reality. Let’s consider a typical interaction that our users have:

In that brief session were a number of distinct interactions:

  • waiting for the page to load,
  • watching an animation,
  • scrolling the page,
  • tapping an icon,
  • watching the navigation animate open,
  • waiting for the page to load,
  • watching an animation,
  • scrolling the page.

Labeling those actions from the video would give us something like this:

A breakdown of the user's journey into RAIL segments12
(View large version13)

Each of those color blocks represents a type of action, and you can see that there are four of them. And there are four letters in RAIL. Curious.

Here’s another user journey that we can break down and label, this time from Voice Memos14:

We can break down user interactions and categorize them into four distinct areas. At Google, we call these areas RAIL, and each comes with its own performance goals, which are based on the human perception thresholds we just saw.

Pauls Irish and Lewis15

The RAIL Performance Model

RAIL stands for response, animation, idle and load.

These four distinct areas are a way to reason about the actions in your websites and apps. If you optimize based on each area’s performance goals (which we got from those perception thresholds), then your users will be very happy.

RAIL Performance Model16

Let’s look at each one in detail.

1. Response Link

If a user clicks on a button, you have to respond to their click before they notice any lag. This applies to any input, really, whether it’s toggling a form control or starting an animation. If it doesn’t happen in a reasonable window of time, then the connection between action and reaction breaks and the user will notice.

Response is all about input latency: the lag between the finger touching the glass and the resulting pixels hitting the screen. Have you ever tapped on something and it took so long to respond that you started wondering whether it registered your tap? That’s exactly the kind of thing we want to avoid!

Response’s primary interaction is:

  • tapping — when the user taps or clicks on a button or icon (for example, tapping a menu icon to open off-screen navigation).

To respond responsively, we would:

  • provide feedback in less than 100 milliseconds after initial input.
  • Ideally, the feedback would show the desired state. But if it’s going to take a long time, then a loading indicator or coloring for the active state will do. The main thing is to acknowledge the user so that they don’t start wondering whether their tap was registered.

2. Animation Link

Animation is a pillar of modern apps, from scrolling to view transitions, and we must be judicious with what we do in this period of time, because the user will often be interacting directly and will really notice if the frame rate varies. However, the user expects very smooth feedback for more than what falls under the classic definition of animation.

Animation includes the following:

  • visual animation
    This includes entrance and exit animations, tweened state changes, and loading indicators.
  • scrolling
    This refers to when the user starts scrolling and lets go and the page is flung.
  • drag
    While we need to respond to the user’s interaction in under 100 milliseconds, animation might follow as a result, as when panning a map or pinching to zoom.

To animate properly, each frame of animation should be completed in less than 16 milliseconds, thereby achieving 60 FPS (1 second ÷ 60 = 16.6 milliseconds).

3. Idle Link

Creating apps that respond and animate well often requires deferment of work. The Optimistic UI17 patterns leverage this technique to great effect. All sorts of work that must be completed likely does not need to happen within a critical time window in the same way as “response” or “load”: Bootstrapping the comments functionality, initializing components, searching and sorting data, and beaconing back analytics data are all non-essential items that we can do when the browser is idle.

To use idle time wisely, the work is grouped into blocks of about 50 milliseconds. Why? Should a user begin interacting, we’ll want to respond to them within the 100-millisecond response window, and not be stuck in the middle of a 2-second template rendering.

4. Load Link

Page-loading time is a well-trodden area of performance. We’re most interested in getting the user to the first meaningful paint quickly. Once that’s delivered, the app must remain responsive; the user mustn’t encounter trouble when scrolling, tapping or watching animations. This can be super-challenging, especially when much of the work for a page shares a single thread.

To load pages quickly, we aim to deliver the first meaningful paint in under 1 second. Beyond this, the user’s attention starts to wander and the perception of dealing with the task at hand is broken. Reaching this goal requires prioritizing the critical rendering path18 and often deferring subsequent non-essential loads to periods of idle time (or lazy-loading them on demand).

Performance Goals

Performance is essentially the art of avoiding work. And when it’s unavoidable, make any work you do as efficient and well timed as possible.

With the stages of RAIL interaction laid out, let’s summarize the goals:

Response Animation Idle Page Load
Tap to paint in less than 100 milliseconds. Each frame completes in less than 16 milliseconds. Use idle time to proactively schedule work. Satisfy the “response” goals during full load.
Drag to paint in less than 16 milliseconds. Complete that work in 50-millisecond chunks. Get first meaningful paint in 1,000 milliseconds.

A Note on Measurement Link

Here are a few handy tips on measuring your project’s performance profile:

  • Measuring these on a MacBook Pro or comparable machine (which many of us designers and developers have) won’t give a representative idea of your mobile users. Common phones can be over ten times slower than a desktop!
  • A Nexus 4 is a good middle-of-the-road device to use.
  • “Regular 3G” is recommended for network throttling.
  • Also, look at your analytics to see what your users are on. You can then mimic the 90th percentile’s experience for testing.

What About Battery and Memory? Link

Delivering on all of the goals above but leaving the user with 10% battery and 0% available memory isn’t putting the user first.

We’re not yet sure how to quantify being a responsible citizen of the shared resources, but RAIL may some day get a B (for battery) and an M (for memory), turning into BLAIMR, PRIMAL or something else equally fun and memorable.

Business Impact Of RAIL Link

Many of us do what we do because we love building awesome things. We don’t work in a vacuum, though, and sometimes we have to make the business case to managers, stakeholders and clients to be able to prioritize performance as part of the user experience.

Luckily, many large companies have shared numbers that help us make our case:

Summary Link

The RAIL model is a lens to look at a user’s experience with a website or app as a journey comprising individual interactions. Once you know each interaction’s area, you will know what the user will perceive and, therefore, what your goals are.

Sometimes it takes extra effort, but if you’re kind to the user, they’ll be good to you.

Resources Link

If you want more information on RAIL and how to optimize your websites and apps, take a look at these.

Presentations on RAIL Link

Guidance and Documentation Link

Performance Audits Link

Academic Research on Perceivable Performance Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7 #rail-perf-model
  8. 8 #rail-perf-goals
  9. 9 /wp-content/uploads/2015/09/img-slow.jpg
  10. 10
  11. 11
  12. 12 /wp-content/uploads/2015/09/img-user-journey-breakdown.jpg
  13. 13 /wp-content/uploads/2015/09/02-user-journey-breakdown-opt.jpg
  14. 14
  15. 15 /wp-content/uploads/2015/09/img-pauls.jpg
  16. 16 /wp-content/uploads/2015/09/img-rail.jpg
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46

↑ Back to top Tweet itShare on Facebook

Paul Irish is a front-end developer who loves the web. He’s thinking a lot about how to make you more productive with tools that improve your workflow help you make slicker, sexier, mobile web sites and webapps. He is also a Developer Advocate for Google Chrome and he works on tools like Modernizr, Yeoman, HTML5 Please, CSS3 Please, and other bits and bobs of open source code.

Paul Lewis works on the Google Chrome team as a Developer Advocate. He spends his days profiling runtime performance issues, and helping developers to build faster sites and apps. Do not be fooled by his extreme baldness; it's a solar panel for his cunning and guile.

  1. 1

    Cristian Jujea

    October 2, 2015 9:54 am

    Think long-term … in five to ten years, every desktop and laptop will have 1TB of space to hold web sites locally … no more HTML, Javascript and CSS performance issues.

    Also, XSLT will be chosen by more and more organizations because they will be able to have internal web pages reside on the client side and connect with SOA applications on the server side.

    • 2

      Eduardo G. Silva

      October 2, 2015 2:14 pm

      People have always thought in the same way than you. This is why software is more bloated now, because they do not optimize it, they always hope for better hardware to run their crappy code. Of course computers will become more powerful, but that does not give you any reason to waste connection data, nor battery or processor cycles.
      On the other hand the technologies you talk about are quite old, and JS is becoming a common choice. Let’s see what comes next.

      • 3

        History shows the opposite, I think. Desktop computers have gotten faster, but then we’ve introduced new form factors, like laptops, then phones, then wearables. Within certain tiers things get faster, but we don’t know what new form factors / tiers of devices will emerge in the future, and history certainly implies that they are slower than the existing ones, at least initially.

        On the upside human perception remains the same: 100ms for a response is true no matter the form factor or platform. That’s one reason why we like RAIL: no matter what you’re building, you have clear, user-centric goals that map to how people perceive their world.

      • 4

        Cristian Jujea

        October 3, 2015 8:45 pm

        Very superficial and childish response on your behalf, kid coder … in 1TB there is space for thousands or tens of thousands of web sites and I’m already there, my first product is a web application which will be downloaded to be run on client’s computers.

        XLST old? You wouldn’t know to how to digest SOA if I put it on a plate and gave you a fork and a knife.

        • 5

          Maybe you could explain exactly what you mean Christian. We all know that storage is cheap but you can’t just store all websites locally, you still need to download them at some point and they’d have to be completely static, otherwise that just isn’t going to work. Unless I’m being thick you’re basically describing caching of assets which browsers already do.

          Besides, how is cahching assets locally going to speed up performance in the browser? It’s not going to help animation speed, paint times etc.

    • 6

      Totally agree with you.
      We don’t need no web-optimisation!

  2. 8

    re: “RAIL is a model for breaking down a user’s experience into key actions.”

    OMG. Did they REALLY have to call it RAIL?

    This is effort helpful. However, I’d like to play Devil’s Advocate for a moment and say that user’s don’t think in term of key actions. The think in terms of accomplishing some goal or goals.

    Put another way, faster key actions isn’t better if the key actions are the wrong actions and/or the user can’t find and use the right ones in the way(s) they are expecting.

    Mind you, this is simply my personal opinion but…

    My greatest day to day frustrations are not with the speed of key actions – tho’ that can be frustrating at times (but I can’t always blame the site so it’s hard to get too upset) – it’s the sloppy if not swear-worthy experiences of too many sites / applications. I’m not talking about your mum’s blog. I’m talking about well-established brands that leave me wondering if they are aware of how sideways their product really is.

    • 9

      I agree, I don’t think users think in terms of actions, either. But we know that context defines expectation. So if you do some kind of animation, we know that the human perception of that will be a) to expect it to be smooth and consistent and b) that breaking a) will be unpleasant.

      What we’re pushing for is for designers and developers to categorize interactions on behalf of the user based on RAIL, and optimize accordingly.

      What you’re tapping into, in many ways, is the design of the experience. If a user can’t find the button or section then the design is fundamentally flawed. However, assuming that the user journey is the right one, then you need to optimize the performance of those journeys.

      RAIL, sure it’s already got Ruby connotations, but LIRA, ARIL, LIAR (yep), and LAIR just weren’t as much fun.

  3. 11

    Nice article.

    Good to see performance being viewed from a user centric angle. It is about experience after all.

    XSLT and SOA? Ha ha, I can only imagine this was tongue in cheek.

  4. 12

    Aren’t devs tired of articles like this—abstract and trivial.

    • 13

      I’ll never tire of abstract or trivial ;)

    • 14

      Performance for many people is fraught with confusion and mixed messages. If we’ve made it sound obvious, then we’ve succeeded in our goal of providing clarity and guiding principles.

      You’re right that we’ve not talked about technical strategies for meeting the RAIL thresholds, but the resources linked just below get into the nuts and bolts. Here we just wanted to outline the guiding philosophy.

  5. 15

    This sounds like a refinement or extension of the old KLM and GOMS models from the 1970s and 1980s:

    Combined, they could prove very useful.

  6. 16

    Madara Uchiha

    October 5, 2015 1:10 pm

    I’ve known RAIL for a while, but what I never got to understand is, how, in the web (i.e. in JavaScript), can you possible divide your work into 50ms blocks in idle? I’ve looked into generators, promises, await/async, and other than simply offloading all the work into a Worker (which is often the best solution, but sometimes not possible due to protocol or access-control limitations), I simply can’t see how you can enforce that.

  7. 18

    its more about LATENCY than speed
    and the biggest bottleneck is too often at the server

    cms platforms that expect the user to wait while they buffer everything for the page instead of sending items as soon as they are ready!

    seems that ALL of them are like that these days

    that has turned me right off using frameworks.

    if the user is left waiting for more than a couple of seconds chances are they will no longer be there when it finally sends that page!

  8. 19

    I like the summarising table. I have a question on the goal of “Getting first meaningful paint in 1,000 milliseconds”: how is that defined? It can’t see how this could be automated easily. You can measure how long the HTML document takes to download or to render, but to only measure the “meaningful” render means making a decision on what’s meaningful and what isn’t.

    • 20

      Jonas Ohlsson

      October 8, 2015 8:22 am

      I think they’re just being very explicit that your first render should involve (somewhat complete) styles for the page in question (which it always will, unless you make a mistake).

      You can automate this at least to some extent. A SpeedIndex graph will visualize for you roughly how complete (and hence meaningful) your renders were over time, including the first one. You can find this kind of info and lots more on the webpagetest website.

  9. 21

    This mentions that Google uses a sites page speed for ranking but links to something from 2010. I am not disputing that fact (because everyone knows that load time for a site is a big factor), but certainly could the impact be different?


↑ Back to top