RAIL モデルでパフォーマンスを測定する

RAIL は、パフォーマンスを考慮するための構造を提供するユーザー中心のパフォーマンス モデルです。このモデルは、ユーザー エクスペリエンスを主要なアクション(タップ、スクロール、読み込みなど)に分割し、各アクションのパフォーマンス目標を定義するのに役立ちます。

RAIL は、ウェブアプリのライフサイクルでレスポンス、アニメーション、アイドル、読み込みの 4 つの側面を表します。ユーザーが期待するパフォーマンスはコンテキストごとに異なるため、パフォーマンス目標は、コンテキストと、ユーザーが遅延をどのように感じるかに関する UX リサーチに基づいて定義されます。

RAIL パフォーマンス モデルの 4 つの要素: レスポンス、アニメーション、アイドル、読み込みです。
RAIL パフォーマンス モデルの 4 つの部分

ユーザーを重視

パフォーマンス改善の取り組みの中心にユーザーを配置します。次の表に、ユーザーがパフォーマンスの遅れをどのように感じるかに関する主な指標を示します。

パフォーマンスの遅れをユーザーが認識している
0 ~ 16 ミリ秒 ユーザーはモーションのトラッキングを得意としており、アニメーションが滑らかでないと嫌悪感を抱きます。毎秒 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 ミリ秒のみであると想定して構いません。この効果を下の図に示します。これは、アイドル状態のタスク中に受信した入力がキューに入れられ、利用可能な処理時間を短縮する方法を示しています。

アイドル状態のタスク中に受信した入力がキューに入れられ、利用可能な入力処理時間が 50 ms に短縮される仕組みを示す図
アイドル状態のタスクが入力レスポンス バジェットに与える影響。

アニメーション: 10 ミリ秒でフレームを生成

目標:

  • アニメーションの各フレームを 10 ミリ秒以内に生成する。技術的には、各フレームの最大バジェットは 16 ms(1,000 ms / 60 フレーム/秒 - 16 ms)ですが、ブラウザでの各フレームのレンダリングに約 6 ms かかるため、1 フレームあたり 10 ms のガイドラインとなっています。

  • 見た目が滑らかになるようにします。ユーザーは、フレームレートが変動することに気づきます。

ガイドライン:

  • アニメーションのような負荷の高い状況では、できる場所では何もせず、できない部分は最低限行うことが重要です。60 fps に達する可能性を最大限に高めるため、可能な限り 100 ミリ秒のレスポンスを利用して、負荷のかかる作業を事前に計算してください。

  • さまざまなアニメーション最適化戦略については、レンダリング パフォーマンスをご覧ください。

  • ビジュアル アニメーション(開始と終了、トゥイーン、読み込みインジケーターなど)。
  • スクロール。これにはフリングが含まれます。フリングとは、ユーザーがスクロールを開始し、その後手を離し、ページがスクロールし続けることです。
  • ドラッグする。多くの場合、アニメーションは地図のパンやピンチ操作によるズームなどのユーザー操作の後に表示されます。

アイドル: アイドル時間を最大化します

目標: アイドル時間を最大化して、ページがユーザー入力に 50 ミリ秒以内に応答する確率を高める。

ガイドライン:

  • アイドル時間を使用して遅延処理を完了します。たとえば、最初のページ読み込みでは、読み込むデータをできるだけ少なくし、アイドル時間を使用して残りの読み込みを行います。

  • 50 ミリ秒以下のアイドル時間中に処理を実行する。それを超えると、50 ミリ秒以内にアプリのユーザー入力に応答できなくなるおそれがあります。

  • ユーザーがアイドル時間中にページを操作した場合、ユーザー操作は常に最も高い優先度で、アイドル時間中の作業を中断する必要があります。

読み込み: コンテンツを配信し、5 秒未満でインタラクティブになる

ページの読み込みが遅いと、ユーザーの注意が散らばり、ユーザーはタスクが壊れていると認識します。読み込みの早いサイトは平均セッション数が長く、直帰率が低く、広告の視認性も高くなります

目標:

  • ユーザーのデバイスとネットワークの機能に応じて、高速読み込みのパフォーマンスが得られるように最適化します。現時点では、3G 接続が低速なミッドレンジのモバイル デバイスで、ページを 5 秒以内にインタラクティブに読み込むことが初回読み込みのターゲットとなります。

  • 後続の読み込みでは、2 秒未満でページが読み込まれることが目標となります。

ガイドライン:

RAIL の測定ツール

RAIL 測定の自動化に役立つツールがいくつかあります。どちらを使用するかは、必要な情報の種類と優先ワークフローの種類によって異なります。

Chrome DevTools

Chrome DevTools では、ページの読み込み中または実行中のすべての事象を詳細に分析できます。パフォーマンス パネルの UI について詳しくは、ランタイム パフォーマンスの分析をはじめようをご覧ください。

次の DevTools 機能が特に関連しています。

灯台

Lighthouse は、Chrome DevTools、PageSpeed Insights、Chrome 拡張機能、Node.js モジュール、および WebPageTest でご利用いただけます。URL を入力すると、低速の 3G 接続を持つミッドレンジのデバイスをシミュレートし、ページで一連の監査を実行し、読み込みパフォーマンスに関するレポートと改善方法の提案を提供します。

次の監査は特に関連します。

対応

読み込み

WebPageTest

WebPageTest は、実際のブラウザを使用してウェブページにアクセスし、速度指標を収集するウェブ パフォーマンス ツールです。webpagetest.org/easy に URL を入力すると、低速の 3G 接続を使用した実際の Moto G4 デバイスで、ページの読み込みパフォーマンスに関する詳細なレポートを取得できます。Lighthouse の監査を含めるように構成することもできます。

概要

RAIL は、ウェブサイトのユーザー エクスペリエンスを、個別のインタラクションで構成されるジャーニーとして捉えるレンズです。ユーザーがサイトをどのように認識しているかを把握し、ユーザー エクスペリエンスに最大の効果をもたらすパフォーマンス目標を設定します。

  • ユーザーへのアピール。

  • ユーザー入力への応答が 100 ミリ秒未満。

  • アニメーション化またはスクロール時にフレームを 10 ミリ秒未満で生成する。

  • メインスレッドのアイドル時間を最大化します。

  • インタラクティブ コンテンツは 5,000 ミリ秒未満で読み込む。