改变DOM结构会使网页变慢? 在<head>中加载script? JavaScript 动画要比CSS3动画效率低? 20ms的操作算不算慢呢? 0.5s? 10s呢?

What does slow mean?

不同的操作需要花费不同的时间来完成,如果离开上下文环境背景很难客观的说什么是快,什么是慢。例如,在浏览器空闲时运行的代码,对于一次触摸操作和一个游戏中的路径循环有不同的性能要求。. Put another way, the people using your website or app have different performance expectationsfor 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 true 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

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 limits. 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 segments
(View large version)

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 Memos:

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.

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 Model

Let’s look at each one in detail.


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.


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).


Creating apps that respond and animate well often requires deferment of work. The Optimistic UI 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.


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 path 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.


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!
  • 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.


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:


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.


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


原文出处: https://www.smashingmagazine.com/2015/10/rail-user-centric-model-performance/





未经允许不得转载:前端学堂fed123(Frontend education) » 如何提升网页用户体验

赞 (2)
分享到:更多 ()

评论 0


登陆 注册