RAIL は、パフォーマンスについて考えるための構造を提供する、ユーザー中心のパフォーマンス モデルです。このモデルは、ユーザー エクスペリエンスを主要なアクション（タップ、スクロール、読み込みなど）に分解し、それぞれのアクションのパフォーマンス目標を定義するのに役立ちます。
RAIL は、ウェブアプリのライフサイクルの 4 つの側面（Response、Animation、Idle、Load）を表しています。ユーザーは、これらのコンテキストごとに異なるパフォーマンスを期待しているため、パフォーマンスの目標は、コンテキストと、ユーザーが遅延をどのように認識するかに関する UX リサーチに基づいて定義されます。
ユーザーを重視
パフォーマンスの取り組みの焦点をユーザーに合わせます。次の表に、ユーザーがパフォーマンスの遅延をどのように認識するかに関する主な指標を示します。
パフォーマンスの遅延に対するユーザーの認識| 0 ～ 16 ミリ秒 | ユーザーは動きを追うのが非常に得意で、アニメーションがスムーズでないと不快に感じます。1 秒間に 60 個の新しいフレームがレンダリングされる限り、アニメーションはスムーズに認識されます。これは 1 フレームあたり 16 ミリ秒に相当し、ブラウザが新しいフレームを画面に描画する時間も含まれます。アプリがフレームを生成するのに使える時間は約 10 ミリ秒です。 |
| 0 ～ 100 ミリ秒 | この時間内にユーザー アクションに応答すると、ユーザーは結果がすぐに表示されたと感じます。これより長いと、アクションとリアクションのつながりが失われます。 |
| 100 ～ 1,000 ミリ秒 | このウィンドウ内では、タスクが自然かつ継続的に進行しているように感じられます。ウェブ上のほとんどのユーザーにとって、ページの読み込みやビューの変更はタスクを表します。 |
| 1,000 ミリ秒以上 | 1,000 ミリ秒（1 秒）を超えると、ユーザーは実行中のタスクに集中できなくなります。 |
| 10,000 ミリ秒以上 | 10,000 ミリ秒（10 秒）を超えると、ユーザーは不満を感じ、タスクを放棄する可能性が高くなります。後で戻ってくる場合もあれば、戻ってこない場合もあります。 |
目標とガイドライン
RAIL のコンテキストでは、目標とガイドラインという用語には特定の意味があります。
目標。ユーザー エクスペリエンスに関連する主要なパフォーマンス指標。たとえば、タップして 100 ミリ秒未満で描画します。人間の知覚は比較的安定しているため、これらの目標がすぐに変わることはありません。
ガイドライン。目標の達成に役立つ推奨事項。これらは現在のハードウェアとネットワーク接続の状態に固有のものであるため、時間の経過とともに変化する可能性があります。
レスポンス: 50 ミリ秒未満でイベントを処理
目標: ユーザー入力によって開始された遷移を 100 ミリ秒以内に完了し、ユーザーが操作を瞬時に感じられるようにします。
ガイドライン:
100 ミリ秒以内に目に見えるレスポンスを返すには、ユーザー入力イベントを 50 ミリ秒以内に処理します。これは、ボタンのクリック、フォーム コントロールの切り替え、アニメーションの開始など、ほとんどの入力に当てはまります。これは、タッチドラッグやスクロールには適用されません。
直感に反するかもしれませんが、ユーザー入力にすぐに応答することが常に正しいとは限りません。この 100 ミリ秒のウィンドウを使用して、他の負荷の高い処理を行うことができますが、ユーザーをブロックしないように注意してください。可能であれば、バックグラウンドで処理を行います。
完了までに 50 ミリ秒以上かかるアクションについては、常にフィードバックを提供します。
50 ミリ秒か 100 ミリ秒か
目標は 100 ミリ秒未満で入力に応答することですが、予算が 50 ミリ秒しかないのはなぜでしょうか。これは、通常、入力処理に加えて他の作業が行われ、その作業が許容可能な入力応答に使用できる時間の一部を占めるためです。アプリケーションがアイドル時間中に推奨される 50 ミリ秒のチャンクで処理を実行している場合、入力がそれらの処理チャンクのいずれかで発生すると、最大 50 ミリ秒間キューに格納される可能性があります。これを考慮すると、実際の入力処理に使用できるのは残りの 50 ミリ秒のみと想定するのが安全です。この効果を視覚化したのが下の図です。アイドルタスク中に受信した入力がキューに入れられ、利用可能な処理時間が短縮される様子を示しています。
アニメーション: 10 ミリ秒でフレームを生成する
目標:
アニメーションの各フレームを 10 ミリ秒以下で生成します。技術的には、各フレームの最大バジェットは 16 ミリ秒（1,000 ミリ秒 / 60 フレーム/秒 ≈ 16 ミリ秒）ですが、ブラウザが各フレームをレンダリングするには約 6 ミリ秒が必要なため、1 フレームあたり 10 ミリ秒というガイドラインが設定されています。
視覚的な滑らかさを目指します。ユーザーはフレームレートの変化に気づきます。
ガイドライン:
アニメーションなど、負荷の高い処理では、可能な限り何もしないこと、そして、どうしても必要な場合でも最小限に抑えることが重要です。可能な限り、100 ミリ秒のレスポンスを利用して負荷の高い処理を事前に計算し、60 fps を達成する可能性を最大化します。
さまざまなアニメーション最適化戦略については、レンダリング パフォーマンスをご覧ください。
- 開始と終了、トゥイーン、読み込みインジケーターなどの視覚的なアニメーション。
- スクロール。これには、ユーザーがスクロールを開始してから指を離し、ページがスクロールし続けるフリックも含まれます。
- ドラッグ。アニメーションは、地図のパンやピンチ操作によるズームなど、ユーザー操作に続いて行われることがよくあります。
アイドル: アイドル時間を最大化する
目標: アイドル時間を最大化して、ページが 50 ミリ秒以内にユーザー入力に応答する可能性を高めます。
ガイドライン:
アイドル時間を使用して、延期された作業を完了します。たとえば、最初のページ読み込みでは、できるだけ少ないデータを読み込み、アイドル時間を使用して残りのデータを読み込みます。
アイドル時間中の作業を 50 ミリ秒以下で実行します。これより長いと、50 ミリ秒以内にユーザー入力に応答するアプリの機能が妨げられる可能性があります。
アイドル時間の処理中にユーザーがページを操作した場合、ユーザー操作を常に最優先し、アイドル時間の処理を中断する必要があります。
読み込み: 5 秒未満でコンテンツを配信し、インタラクティブにする
ページの読み込みが遅いと、ユーザーの注意が散漫になり、タスクが中断されたと感じます。読み込みが速いサイトは、平均セッション時間が長く、直帰率が低く、広告の視認性が高い傾向にあります。
目標:
ユーザーのデバイスとネットワークの機能に応じて、読み込みパフォーマンスを最適化します。現在、最初の読み込みの適切な目標は、低速の 3G 接続を使用するミッドレンジのモバイル デバイスで 5 秒以下でページを読み込み、インタラクティブにすることです。
それ以降の読み込みでは、2 秒未満でページを読み込むことを目標にしてください。
ガイドライン:
ユーザーが一般的に使用しているモバイル デバイスとネットワーク接続で、読み込みパフォーマンスをテストします。Chrome ユーザー エクスペリエンス レポートを使用すると、ユーザーの接続分布を確認できます。サイトのデータが利用できない場合は、The Mobile Economy 2019 で、Moto G4 などのミッドレンジの Android スマートフォンと低速の 3G ネットワーク（400 ms RTT と 400 kbps の転送速度と定義）をグローバルなベースラインとして推奨しています。この組み合わせは WebPageTest で利用できます。
一般的なモバイル ユーザーのデバイスは、2G、3G、4G 接続を使用していると表示されることがありますが、実際には、パケットロスやネットワークの変動により、実効接続速度が大幅に低下することがよくあります。
完全に読み込まれたという認識を生み出すために、5 秒以内にすべてを読み込む必要はありません。画像の遅延読み込み、JavaScript バンドルのコード分割、web.dev で推奨されているその他の最適化を検討してください。
RAIL を測定するためのツール
RAIL 測定の自動化に役立つツールがいくつかあります。どちらを使用するかは、必要な情報の種類と、好みのワークフローの種類によって異なります。
Chrome DevTools
Chrome DevTools では、ページの読み込み中または実行中に発生するすべての事象を詳細に分析できます。[パフォーマンス] パネルの UI については、ランタイム パフォーマンスの分析を始めるをご覧ください。
特に、次の DevTools 機能が関連しています。
CPU をスロットリングして、性能の低いデバイスをシミュレートします。
ネットワークをスロットルして、低速接続をシミュレートします。
メインスレッドのアクティビティを表示して、記録中にメインスレッドで発生したすべてのイベントを確認します。
メインスレッドのアクティビティをテーブルに表示して、最も時間がかかったアクティビティに基づいてアクティビティを並べ替えます。
フレーム/秒（FPS）を分析して、アニメーションが実際にスムーズに実行されているかどうかを測定します。
Performance Monitor を使用して、CPU 使用率、JS ヒープサイズ、DOM ノード、1 秒あたりのレイアウト数などをリアルタイムでモニタリングします。
[ネットワーク] セクションで、記録中に発生したネットワーク リクエストを可視化します。
記録中にスクリーンショットをキャプチャして、ページの読み込み中やアニメーションの起動中などにページがどのように表示されたかを正確に再生します。
インタラクションを表示すると、ユーザーがページを操作した後に何が起こったかをすばやく特定できます。
問題のあるリスナーが起動するたびにページをハイライト表示して、スクロール パフォーマンスの問題をリアルタイムで検出します。
ペイント イベントをリアルタイムで表示して、アニメーションのパフォーマンスを低下させる可能性のある、コストの高いペイント イベントを特定します。
灯台
Lighthouse は、Chrome DevTools、PageSpeed Insights、Chrome 拡張機能、Node.js モジュール、WebPageTest で利用できます。URL を指定すると、低速の 3G 接続を使用するミッドレンジ デバイスをシミュレートし、ページに対して一連の監査を実行して、読み込みパフォーマンスに関するレポートと改善方法に関する提案を提供します。
特に、次の監査が関連しています。
レスポンス
最大潜在初回入力遅延。メインスレッドのアイドル時間に基づいて、アプリがユーザー入力に応答するまでにかかる時間を推定します。
Total Blocking Time。ユーザー入力（マウスのクリック、画面のタップ、キーボードの押下など）への応答がブロックされている合計時間を測定します。
Time to Interactive。ユーザーがすべてのページ要素を安定して操作できるようになるまでの時間を測定します。
読み込み
ページと start_url を制御する Service Worker が登録されていません。サービス ワーカーは、ユーザーのデバイスに共通のリソースをキャッシュに保存できるため、ネットワーク経由でリソースを取得する時間を短縮できます。
オフスクリーン画像の遅延読み込みを行う。画面外の画像の読み込みを、必要になるまで遅らせます。
適切なサイズの画像を使用する。モバイル ビューポートでレンダリングされるサイズよりも大幅に大きい画像は配信しないでください。
過度な DOM サイズを回避する。ページのレンダリングに必要な DOM ノードのみを送信することで、ネットワーク バイト数を削減します。
WebPageTest
WebPageTest は、実際のブラウザを使用してウェブページにアクセスし、タイミング指標を収集するウェブ パフォーマンス ツールです。webpagetest.org/easy で URL を入力すると、低速の 3G 接続を使用する実際の Moto G4 デバイスでのページの読み込みパフォーマンスに関する詳細なレポートを取得できます。また、Lighthouse 監査を含めるように構成することもできます。
概要
RAIL は、ウェブサイトのユーザー エクスペリエンスを、個別のインタラクションで構成されるジャーニーとして捉えるためのレンズです。ユーザーがサイトをどのように認識しているかを把握し、ユーザー エクスペリエンスに最も大きな影響を与えるパフォーマンスの目標を設定します。
ユーザーへのアピール。
ユーザー入力に 100 ミリ秒未満で応答する。
アニメーションやスクロールの際に、10 ミリ秒未満でフレームを生成する。
メインスレッドのアイドル時間を最大化する。
インタラクティブなコンテンツを 5,000 ミリ秒未満で読み込む。