Measure Performance with the RAIL Model

RAIL is a user-centric performance model that breaks down the user's
experience into key actions. RAIL's goals and guidelines aim to
help developers and designers ensure a good user experience for each of these actions. By
laying out a structure for thinking about performance, RAIL enables designers and developers to
reliably target the work that has the highest impact on user experience.

Every web app has four distinct aspects to its life cycle, and performance fits into them in
different ways:

Figure 1. The 4 parts of the RAIL performance model

Goals and guidelines

In the context of RAIL, the terms goals and guidelines have specific meanings:

Goals. Key performance metrics related to user experience. Since human perception is
relatively constant, these goals are unlikely to change any time soon.

Guidelines. Recommendations that help you achieve goals. These may be specific to current
hardware and network connection conditions, and therefore may change over time.

Focus on the user

Make users the focal point of your performance effort. The table below describes key metrics of
how users perceive performance delays:

User Perception Of Performance Delays

0 to 16ms

Users are exceptionally good at tracking motion, and they
dislike it when animations aren't smooth. They perceive animations as smooth so long as
60 new frames are rendered every second. That's 16ms per frame, including the time it
takes for the browser to paint the new frame to the screen, leaving an app about 10ms to
produce a frame.

0 to 100ms

Respond to user actions within this time window and users
feel like the result is immediate. Any longer, and the connection between action and
reaction is broken.

100 to 300ms

Users experience a slight perceptible delay.

300 to 1000ms

Within this window, things feel part of a natural and
continuous progression of tasks. For most users on the web, loading pages or changing
views represents a task.

Beyond 10000 milliseconds (10 seconds), users are frustrated
and are likely to abandon tasks. They may or may not come back later.

Users perceive performance delays differently, depending on network conditions and hardware.
For example, loading an experience in 1000ms is plausible on a powerful desktop machine over a
fast Wi-Fi connection, so users have grown accustomed to a 1000ms loading experience. But for
mobile devices over slow 3G connections, loading in 5000ms is a more realistic goal, so mobile
users are generally more patient.

Response: respond in under 50ms

Goal: Complete a transition initiated by user input within 100ms. Users spend the majority
of their time waiting for sites to respond to their input, not waiting for the sites to load.

Guidelines:

Respond to user input within 50ms, or else the connection between action and
reaction is broken. This applies to most inputs, such as clicking buttons, toggling form
controls, or starting animations. This does not apply to touch drags or scrolls.

Though it may sound counterintuitive, it's not always the right call to respond to user
input immediately. You can use this 100ms window to do other expensive work. But be
careful not to block the user. If possible, do work in the background.

For actions that take longer than 50ms to complete, always provide feedback.

Animation: produce a frame in 10ms

Goals:

Produce each frame in an animation in 10ms or less. Technically, the maximum budget for
each frame is 16ms (1000ms / 60 frames per second ≈ 16ms), but browsers need about 6ms to
render each frame, hence the guideline of 10ms per frame.

Aim for visual smoothness. Users notice when frame rates vary.

Guidelines:

In high pressure points like animations, the key is to do nothing where you
can, and the absolute minimum where you can't. Whenever possible, make use of
the 100ms response to pre-calculate expensive work so that you maximize your
chances of hitting 60fps.

Optimize for fast loading performance relative to the device and network capabilities that
your users use to access your site. Currently, a good target for first loads is to load the
page and be interactive in 5 seconds or less on mid-range mobile devices with slow
3G connections. See Can You Afford It? Real-World Web Performance Budgets. But be
aware that these targets may change over time.

For subsequent loads, a good target is to load the page in under 2 seconds. But this target
may also change over time.

Figure 2. Each loading metric represents a different phase of the user's perception of
the loading experience

Guidelines:

Test your load performance on the mobile devices and network connections that are common
among your users. If your business has information on what devices and network connections your
users are on, then you can use that combination and set your own loading performance targets.
Otherwise, The Mobile Economy 2017 suggests that a good global baseline is a
mid-range Android phone, such as a Moto G4, and a slow 3G network, defined as 400ms RTT and
400kbps transfer speed. This combination is available on WebPageTest.

Keep in mind that although your typical mobile user's device might claim that it's on a 2G, 3G,
or 4G connection, in reality the effective connection speed is often significantly slower,
due to packet loss and network variance.

You don't have to load everything in under 5 seconds to produce the perception of a complete
load. Enable progressive rendering and do some work in the background. Defer non-essential
loads to periods of idle time. See Website Performance Optimization.

Recognize the factors that affect page load performance:

Network speed and latency

Hardware (slower CPUs, for example)

Cache eviction

Differences in L2/L3 caching

Parsing JavaScript

Tools for measuring RAIL

There are a few tools to help you automate your RAIL measurements. Which one you use depends
on what type of information you need, and what type of workflow you prefer:

Chrome DevTools. The developer tools built into Google Chrome. Provides
in-depth analysis on everything that happens while your page loads or runs.

Lighthouse. Available in Chrome DevTools, as a Chrome Extension, as a
Node.js module, and within WebPageTest.
You give it a URL, it simulates a mid-range device with a slow 3G connection, runs a
series of audits on the page, and then gives you a report on load performance, as well
as suggestions on how to improve. Also provides audits to improve
accessibility, make the page easier to maintain, qualify as a Progressive Web App, and more.

WebPageTest. Available at
webpagetest.org/easy. You give
it a URL, it loads the page on a real Moto G4 device with a slow 3G connection, and then gives
you a detailed report on the page's load performance. You can also configure it to include a
Lighthouse audit.

The sections below give you more information on how to use each tool to measure RAIL.

WebPageTest

Enter a URL at webpagetest.org/easy to get a report on how that
page loads on a real mid-range Android device with a slow 3G connection.

Figure 4. An example WebPageTest report

Summary

RAIL is a lens for looking at a website's user experience as a journey composed of distinct
interactions. Understand how users perceive your site in order to set performance goals with the
greatest impact on user experience.