RAIL はユーザーを中心に考えるパフォーマンス モデルです。すべてのウェブアプリのライフサイクルには 4 つの異なる側面があり、これらの側面に適したパフォーマンスはそれぞれ異なります。
TL;DR
- ユーザーを第一に考えます。最終目標は、特定の端末でのサイトの処理速度を上げることではありません。ユーザーが満足感を得ることが最終目標です。
- ユーザーに対して即座に応答します。ユーザー入力は、100 ミリ秒以内に認識します。
- アニメーションやスクロールでは、10 ミリ秒以内にフレームを生成します。
- メインスレッドのアイドル時間を最大限に活用します。
- ユーザーの作業を妨げません。インタラクティブ コンテンツは 1000 ミリ秒以内に提供します。
ユーザー第一
パフォーマンス改善に取り組む際はユーザーを第一に考えます。ユーザーがサイトに費やす時間の大半が、サイトの読み込みを待つ時間ではなく、サイトを使用しながらレスポンスを待つ時間になるようにします。パフォーマンスが低下すると、ユーザーがどのように感じるかを理解します。
| 遅延 & ユーザーの反応 | |
|---|---|
| 0～16 ミリ秒 | 人は非常に動作の追跡が得意なので、アニメーションがスムーズでなければ不満を持ちます。 画面が 1 秒間あたり 60 回更新されると、スムーズなアニメーションであると感じます。これは 1 フレームあたり 16 ミリ秒となり、ブラウザが新しいフレームを画面に描画する時間が含まれるため、アプリがフレームを生成できる時間は約 10 ミリ秒です。 |
| 0～100 ミリ秒 | この時間内にユーザーのアクションに応答すると、ユーザーはすぐに結果が得られたと感じます。これより時間がかかると、操作と反応にずれが生じます。 |
| 100～300 ミリ秒 | ユーザーはやや遅いと感じます。 |
| 300～1000 ミリ秒 | この時間内に収まれば、途切れることなく自然にタスクが進んでいると感じられます。ウェブを利用する大部分のユーザーにとってのタスクとは、ページの読み込みやビューの切り替えを指します。 |
| 1,000 ミリ秒以上 | 1 秒を超えると、ユーザーは実行したタスクへの関心を失います。 |
| 10,000 ミリ秒以上 | ユーザーは不満を感じてタスクを中断し、そのまま戻ってこない恐れがあります。 |
レスポンス: 100 ミリ秒以内にレスポンスを返す
ユーザーの入力に 100 ミリ秒以内にレスポンスを返せば、ユーザーは遅れを感じません。この時間は、ユーザーによるボタンのクリック、フォーム上のコントロールの切り替え、アニメーションの開始など、すべての入力に当てはまります。 ただし、タッチ操作やスクロールにはあてはまりません。
この時間内にレスポンスが返らないと、操作と反応にずれが生じるため、ユーザーは遅れを感じます。
ユーザーの操作に対してすぐにレスポンスを返すのは当然だと思うかもしれませんが、タイミングよく返せないこともあります。その場合はこの 100 ミリ秒を利用して、他の負荷の高い処理を実行します。ただし、ユーザーの妨げにならないよう注意して、可能であればバックグラウンドで処理を実行します。
操作に 500 ミリ秒以上かかる場合は、必ずフィードバックを提供します。
アニメーション: 10 ミリ秒間隔でフレームをレンダリングする
アニメーションは、単に美しい UI 効果というだけではありません。たとえば、スクロールやタッチ操作も一種のアニメーションです。
アニメーションのフレームレートが一定でなければ、ユーザーはすぐに気付きます。目標は、1 秒あたり 60 フレームとし、各フレームでは以下の手順を実行します。
単純計算では、各フレームには約 16 ミリ秒の割り当てがあります（1 秒を 60 フレームで除算 = 16.66 ms / フレーム）。 しかし、ブラウザが新しいフレームを画面に描画する時間が必要になるため、アニメーション中にコードで実際に使用できる時間は 10 ミリ秒程度です。
アニメーションのように負荷の高い処理では、できる限り何も行わず、必要最小限の処理にとどめることが重要です。 可能であれば、100 ミリ秒のレスポンス時間を利用して負荷の高い処理を事前に実行し、60 fps を実現できる可能性を最大限に高めます。
詳細については、レンダリング パフォーマンスを参照してください。
アイドル: アイドル時間を最大限に活用する
アイドル時間を利用して遅延している作業を完了します。たとえば、データのプリロードを最小限に抑えてアプリの読み込みを高速にし、残っているデータはアイドル時間に読み込みます。
遅延している作業は 50 ミリ秒程度のブロックにグループ化します。ユーザーが操作を始めた場合は、その操作にレスポンスを返すことが最優先です。
100 ミリ秒以内にレスポンスを返すためには、アプリで毎回 50 ミリ秒以内にメインスレッドに制御を返す必要があります。そうすることで、ピクセル パイプラインの実行や、ユーザー入力への反応などが可能になります。
50 ミリ秒単位のブロックにすることによって、即座にレスポンスを返しながら、タスクを完了できます。
読み込み: 1,000 ミリ秒以内にコンテンツを提供する
サイトは 1 秒以内に読み込みます。それよりも時間がかかると、ユーザーの集中力が切れ、タスクの操作に失敗したと感じます。
クリティカル レンダリング パスの最適化に重点を置き、スムーズなレンダリングを行います。
実際にすべてを 1 秒以内に読み込む必要はなく、読み込みが終わったと感じられるようにします。プログレッシブ レンダリングを有効にして、一部の処理をバックグラウンドで実行します。重要度の低い読み込みは、アイドル状態になるまで延期します（詳細については、ウェブサイト パフォーマンスの最適化に関する Udacity コースをご覧ください）。
RAIL の重要なメトリクスの概要
RAIL のメトリクスに照らしてサイトを評価するには、Chrome DevTools の Timeline ツールを使用してユーザーの操作を記録します。その後、RAIL の重要なメトリクスに照らして Timeline の記録時間をチェックします。
| RAIL のステップ | 重要なメトリクス | ユーザーの操作 |
|---|---|---|
| レスポンス | 入力レイテンシ（タップからペイントまで）は 100 ミリ秒未満 | ユーザーがボタンをタップする（例: ナビゲーションを開く）。 |
| アニメーション | 各フレームの処理（JS からペイントまで）は 16 ミリ秒未満 | ユーザーがページをスクロールし、指をドラッグする（例: メニューを開くため）、アニメーションを見る。ドラッグ中は、指の位置に応じてアプリでレスポンスをする（プルして更新、カルーセルのスワイプなど）。このメトリクスはドラッグの開始時点ではなく、継続中にのみ適用されます。 |
| アイドル | 。メインスレッドの JS 処理ブロックは 50 ミリ秒以内 | ユーザーがページを操作していなくても、次のユーザー入力を十分処理できるようメインスレッドを利用可能な状態にする。 |
| 読み込み | ページを使用する準備が整うまで 1,000 ミリ秒以内 | ユーザーがページを読み込み、クリティカル パス コンテンツを表示する。 |