🥁 💈 ⏪ RAILの紹介：サイトパフォーマンス評価モデル 🤘🏻 🦒 🕑

最近、サイトのパフォーマンスの最適化に関する多くのヒントが公開されています。「DOMが遅すぎる」や「CSSアニメーションを常に使用する」といったフレーズはキャッチーなタイトルですが、物事の本当の状態にはさまざまなニュアンスがあります。

Google ChromeチームのPaul IrishとPaul Lewisによる、サイトのパフォーマンスを評価するモデルについての記事を紹介しています。安全にユーザー中心のパフォーマンスと呼ぶことができます。
たとえば、今日最も人気のあるトピックであるページの読み込み時間を考えてみましょう。問題は、誰かが速度インデックスを計算するためにかなり複雑な式を使用し、誰かがbody.onloadで、誰かがDOMContentLoadedで、またはおそらく他のイベントで測定することです。

サイトのパフォーマンスの最適化に専念できる限りの時間はないため、最適化に重要なものとそうでないものの基準を検討する必要があります。また、ユーザーにとって「生産的なサイト」という言葉が何を意味するかについても同意する必要があります。これは、ユーザー専用のサイトを作成するためです。

Air.rfチームなど、世界中の多くのチームがWebサイトのパフォーマンスの概念に取り組んでおり、一緒になって、ユーザーをこのパフォーマンスストーリーの中心と見なすモデルになりました。このモデルは、RAIL = Response + Animation + Idle + Loadと呼ばれていました。

簡単に言えばRAILとは：

RAILは、ユーザーエクスペリエンスがいくつかの主要なアクションに分類されるモデルです。たとえば、クリック、ドラッグ（マウスボタンまたはタッチパッドでの移動）、スクロール、読み込み。
RAILは、これらのアクティビティのパフォーマンス目標を設定します。たとえば、クリックからそのクリックでのレンダリングアクションに渡されるのは100ミリ秒以内でなければなりません。
RAILは、生産性を向上させるための作業を計画するためのフレームワークを提供します。設計者と開発者はそれらの瞬間を特定し、その改善が最大の影響を与えることができ、それらに取り組むことができます。

RAILモデルを詳細に分解する前に、もう1つの中間ステップを実行して、最も愛されていない「ゆっくり」という言葉に対処しましょう。

「ゆっくり」

「遅い」とはどういう意味ですか？ DOMで何かを変更する-遅い？ <head>セクションの<script>タグはどうですか？ JavaScriptアニメーションはCSSアニメーションより遅いですよね？操作に20ミリ秒かかる場合、遅いですか？そして0.5秒なら？そして10秒なら？

異なる操作を完了するには異なる時間を必要としますが、それがどれほど速いか遅いかを客観的に言うのは困難です。これが発生するコンテキストに注意を払うことが重要です。

たとえば、コードのさまざまな部分：1つ-画面上で何も起こらないときに動作し、もう1つ-プレイヤーが自分のアクションに特定の反応を期待するゲームサイクルのときに、異なるパフォーマンス要件があります。サイトまたはアプリケーションのユーザーは、使用状況に応じてパフォーマンスに関して異なる期待を抱きます。

UXのあらゆる側面と同様に、ユーザーがどのように認識するかが最も重要です。 Googleで作業する最初の「命令」は、「ユーザーの利益-そもそも、他のすべてが来る」ように聞こえます。

したがって、何らかのアクションが「ゆっくり」実行されているかどうかを評価することは無意味です。「 ユーザーが私たちがやったことを操作したときにユーザーが感じること」を見つける必要があります。

「パフォーマンス」の概念の中心にあるユーザー

幸いなことに、ユーザーがサイトやアプリケーションの反応速度をどのように認識しているかについて多くの研究があります。たとえば、これはJacob Nielsenの研究です。これらの結果に基づいて、私たちは自分自身のために以下を策定しました：

100ミリ秒 ：この時間中にユーザーのアクションに応答する必要があり、ユーザーは反応が即座に行われたことを認識します。これよりも長いと、アクションとリアクションの間に遅延感が生じます。
1秒：ユーザーが「タスク」の完了を感じる時間は自然です。「タスク」とは、たとえば、フィルターが変更されたときにページをロードしたり、製品のリストを変更したりすることです。
16ミリ秒 ：ほとんどのデバイスで画面が毎秒60回更新されることを考慮して、そのような時間に次のフレームが画面に表示されるようにします（1000/60 = 16）。人々は目の動きを非常によく追跡し、1秒あたり60フレームより遅い速度は期待に反します。

これらの制限は、私たちが構築できる基盤を設定するという点で非常に優れています。

ユーザーインタラクションの典型的な例を見てみましょう。

この短い例では、いくつかの異なるタイプの対話がありました。

ページの読み込みを待機しています
アニメーションを見る
ページスクロール
アイコンをクリックする
ナビゲーションブロックのアニメーション化された開口部を表示する
ページの読み込みを待機しています
アニメーションを見る
ページスクロール

ビデオの全期間を通じてこれらのタイプのインタラクションをマークアップすると、次のような画像が得られます。

以下の別のビデオでは、これらのタイプのユーザーインタラクションの例を示します。

すべてのタイプのユーザーインタラクションを4つのタイプに分類できます。 GoogleはこれらのタイプのインタラクションをRAILと呼び、そのようなタイプのインタラクションにはそれぞれ、前述の人間の知覚のしきい値に基づく独自のパフォーマンス目標があります。

レール性能モデル

RAILは、英語の応答（応答）、アニメーション（アニメーション）、アイドル（待機）、ロード（ロード）の略語です。これら4つの領域は、サイトおよびアプリケーションのパフォーマンスの最適化を検討するために検討する必要があります。ユーザーが期待する反応時間に基づいて最適化すれば、ユーザーは満足します。

応答

ユーザーがボタンをクリックすると、ラグに気付かないようにアクションに非常に迅速に「応答」する必要があります。これは、ユーザー入力のすべての要素に適用されます。ユーザーがフォームのスイッチをクリックするか、通常のボタンをクリックするかは関係ありません。ユーザーがスイッチのオン/オフ、ボタンを押すアニメーションなど、システムの応答をすばやく確認できない場合、システムのアクションと反応の間にギャップが生じます。それから彼は、システムが遅れて動作していると感じます。

応答は、サイトまたはアプリケーションのソフトウェア部分のみに関連しているわけではありません。これは、ユーザーの指がスマートフォンのガラスに触れた方法と、それを押した結果が画面に描画される方法との間に生じる遅延です。

そしてここでは、ウェブサイトまたはアプリケーションの遅延だけでなく、クリックの認識を担当するスマートフォンのファームウェアの「計算」も重要です。ボタンを押すようなことをしたことがありますが、遅延が非常に大きいので、デバイスがそのボタンを押したと「理解」したのではないかと疑い始めますか？これはまさにユーザーに表示されるべきではない感覚です。

それ自体が否定的であるという事実に加えて、それが動作するアプリケーションの一般的な信頼性、またはチームがサイトをどの程度専門的に作成したかについて、合理的な疑念を提起します。ユーザーに対する同様の疑念は、製品のイメージに反することになります。

正しい応答は、ユーザーアクション後100ミリ秒未満で発生します。

理想的には、応答はすぐに目的の新しい状態につながるはずです。これができない場合は、ユーザーにデバイスまたはアプリケーションがクリックに応答しなかったと感じさせないように、進行状況インジケーターをユーザーに表示する必要があります。

アニメーション

アニメーションは、あらゆる種類の最新のアプリケーションに存在します。アニメーションとは、もちろん、「描かれたウサギが画面上を移動する」のではなく、スクロール、横に伸びるメニュー、画面の内容が時間とともに継続的に変化しなければならないという事実に関連する他の同様の効果などの操作を意味します。

アニメーションはタイプ別に分類できます。

視覚的または通常 ：従来のアニメーションスクリーンセーバー、ダウンロードインジケーター、ステータスインジケーターなど、つまり、画面上で何らかのアニメーションフラグメントのように見えるものが含まれます。
スクロールアニメーション ：通常、これはアニメーションのようには見えませんが、技術的にはそうです。ユーザーが通常のコンピューターで画面上で指をスワイプするか、マウスまたはタッチパッドでスクロールすると、画面上の画像が常に変化します。

ドラッグアニメーション：ユーザーがアプリケーションまたはサイトの一部の機能を使用する場合。これは、画面上の一部の領域をクリックしてから、押した状態で横に「引っ張る」ことを意味します。画面をスケーリングしたり、オブジェクトを「ドラッグ」したりすることができます。

アニメーションを連続的に見えるようにするには、アニメーションの各フレームが16ミリ秒未満で 、つまり60 FPSの速度で画面に表示される必要があります 。（1秒/ 60フレーム=フレームあたり16.6ミリ秒）。

待機中（アイドル）

多くのプロセスは各アプリケーション内で行われますが、アプリケーションが「応答」や「アニメーション」などのユーザーとの対話に取り組んでいるような重要な瞬間にすべてが機能するわけではありません。

さまざまなコンポーネントの初期化、データの検索と並べ替え、分析サービスへのデータの送信：これらはすべて、アプリケーションまたはブラウザーがスタンバイモードのときに一度に実行できます。

タイムアウトを正しく使用するには、この時点で実行されるタスクを50ミリ秒以下のブロックにグループ化する必要があります 。なぜそうユーザーがインタラクションを開始した場合、アプリケーションが何かを行ってアクションに応答できない間、2秒間待たせずに、100ミリ秒で応答することができます。

負荷

まず、ユーザーに最初の画面をできるだけ早く表示したいのですが、それでもユーザーは自分に役立つ十分な情報を表示する必要があります。メニューの見出しを見せてから、残りの情報が表示されるのを待つだけでは良くありません。最初の画面がユーザーに表示されるとすぐに、アプリケーションまたはサイトは、ページの残りがバックグラウンドでロードされている場合でも、ユーザーのアクションに応答する機能を保持する必要があります。ただし、この時点でも、スクロール、クリック、アニメーションの問題は発生しないはずです。

「高速ダウンロード」について話すとき、最初の画面を1秒でユーザーに表示するという目標を設定します 。そうしないと、ユーザーはプロセスが「中断」されたように感じ、「ゆっくり実行されている」と考え、何かに気が散ることがありますその後、他の人に。彼は、このサイトからブラウザで別のブックマークに切り替えることができます。

1秒以内にページを表示する時間を確保するには、重要でない要素のすべてのダウンロードをユーザーのアクションを待つ時間まで延期する必要があります。

まとめ

結論として、RAILの概念におけるサイトとアプリケーションのパフォーマンスの目標を思い出します。

応答	アニメーション	待ってる	読み込み中
ユーザーアクションに対する「インスタント」応答	「理解できない」アニメーションの感覚	重要ではないアクションの実行	ページの読み込み中に応答目標を維持する
100ミリ秒未満で相互作用を引き出す	16ミリ秒未満ですべてのフレームを表示します	50ミリ秒未満ですべてのアクションを完了する	1秒後に最初の画面を表示する

測定に関するいくつかの言葉：

最新のMacBook Pro（デザイナーや開発者の間で非常に人気のあるマシン）でのユーザーインタラクションの速度を測定することは、モバイルデバイスのユーザーは言うまでもなく、平均的なユーザーにとっても代表的なものではありません。
平均的なパフォーマンスのスマートフォンを使用します。
また、「通常の3G」インターネット接続を使用して、LTEなどの高度な標準を使用せずに、オフィスで非常に高速なインターネット接続を使用せずに、相互作用をテストします。
サイト/アプリケーションの統計情報を使用して、ユーザーが使用しているデバイスを把握します。その後、そのようなデバイスの大部分でサイト/アプリケーションの動作をシミュレートできます。

また、デバイスのバッテリーとメモリを責任を持って使用することの重要性にも留意したいと思います。これらのすべてのパフォーマンス目標を達成しますが、ユーザーに10％のバッテリー電力とフルメモリを残すことは、「ユーザーの関心、まず第一」ではありません。

これまでのところ、バッテリーの電力とメモリの使用に関する明確な基準を開発していませんが、おそらくB（バッテリー用）とM（メモリー用）を略語に追加するでしょう。これらの点は無視できないためです。

サイトのパフォーマンスを最適化することの重要性は、よく知られているいくつかのケースで確認されています。

そしてもちろん、Googleは検索ページのランキングの要因の1つとしてダウンロード速度を使用していることを忘れないでください。

RAILの紹介：サイトパフォーマンス評価モデル

「ゆっくり」

「パフォーマンス」の概念の中心にあるユーザー

レール性能モデル

応答

アニメーション

待機中（アイドル）

負荷

まとめ

More articles: