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