One Step Ahead

プログラミングやエンジニアリング全般について書いていきます

画面のレスポンスタイム指標

はじめに

パフォーマンスのテスト計画を作成するにあたり、画面のレスポンスタイムに関する指標を調べる機会があったので、そのまとめです。

画面レスポンス(応答性)の早さはどうして重要なのか?

まずはどうして、応答性の早さが求められるのかという点ついてです。
『Website Response Times』の中で、応答性について2つの観点から、その重要性を述べていました。

1. 人間の能力的観点

記憶力と注意力といった観点からみても、Webレスポンスが長くなることはあまり好ましくありません。
ワーキングメモリ自体は特定の期間、繰り返し思考されたりしない限り、長期記憶には残らないとされており、ワーキングメモリ内の情報の持続時間はおおよそ10~15秒とされています。そして、もちろん個人差があります。
そのため、10秒を超えるようなレスポンスは作業パフォーマンスの低下を引き起こすとされているそうです。

2. 人間の願望的観点

コンピューターを操作するとき、私たちはコンピューターに対して無意識のうちに従順であることを期待しています。検索の結果を気まぐれに返したり、クリックに反応する場合があったりなかったりすることはなく、私たちが操作した内容に対して、正確かつ迅速で、的確であることを期待しています。
なので、少しでも自分の期待に添わないような動き、例えば...

『クリックに反応しない。』
『検索結果のレスポンスにばらつきがある。』

といった場合には、『期待に背かれた』と感じてストレスを感じてしまいます。

応答時間の制限(3 response-time limits)

応答時間の基準に関しては、1993年の段階で3つの指標が出されています。

応答時間 0.1秒

ユーザーは、自身の操作に対して瞬時に反応しているような感覚を得ます。
リアルタイムの操作性が求められる機能に関しては、この秒数内に収めることがほぼ必須とされます。

応答時間 1秒

1秒程度の応答時間であれば、一瞬の遅延は感じることはあっても作業や思考自体が分断されるような感覚になることはありません。 この程度であれば、ユーザーはコントロール性をもってコンピューターを操作していると感じることができます。

応答時間 10秒

ユーザーの注意力が持続するのは1~10秒程度なので、ここが限界値です。
ユーザーから、ギリギリ許せるか...といったところです。明らかな遅延を感じ、コントロール性は失われているため、ユーザー体験としては決して良いものではありません。

応答時間の制限(RAIL model)

次にRAILモデルからみた、応答時間の制限についてです。
RAILモデルは、Google Web Fundamentalsで公開されている、『ユーザーファーストに基いて考えられた、ユーザーを中心に考えるパフォーマンスモデル』のことです。
このモデルは、以下の4つの要素から構成されています。

  • Response（応答速度）
  • Animation（動き）
  • Idle（静止状態）
  • Load（読み込み速度）

今回はあくまで、『画面のレスポンスタイム指標』がお題なので、Responseについてフォーカスします。

応答時間 0~16ミリ秒

ページ内動作であれは最高です。Good。
ただ、ユーザーはモーショントラッキングに長けているので、『アニメーション』ということであれば話は変わってきます。
ユーザーは毎秒60フレームがレンダリングされている限り、アニメーションに遅延を感じません。 逆にそれを超えるとユーザーは、アニメーションの遅延を認識し始めます。そのため、16ミリ秒という数値はアプリケーションのフレーム間隔でいえばギリギリということになります。

応答時間 0~100ミリ秒

この時間内であれば、ユーザーは即時に応答されていると感じます。これ以上長くなると、ユーザーは自分のアクションとリアクションの乖離を感じ始めます。

応答時間 100~300ミリ秒

ページ内の動作などであれば、ユーザーは遅延を感じ始めます。

応答時間 300~1000ミリ秒

ページの読み込みなど、ページ内動作以外であれば、スムーズな体験を提供しているというレベルです。 ページ内動作であれば、上記同様に遅延を感じ、アクションとリアクションの乖離を感じている状態です。

応答時間 1,000ミリ秒以上

1秒(1,000ミリ秒)を超えると、ユーザーは自身が実行したタスクへの関心を失い始めています。

応答時間 10,000ミリ秒以上

10秒(10,000ミリ秒)を超えると、ユーザーはイライラしてタスクをほぼ放棄している可能性が非常に高いです。ユーザーはもう戻ってこないかも知れません。

2つの指標から見えること

応答時間は場面とタスクに応じて

単純に『応答時間』だけをみて遅い云々の議論はできない。というのは非常に重要なことかなと思います。 上の指標だけでも、『アニメーション』『ページ内』『ページ読み込み』という3つが示されています。1秒はページ内では遅いかも知れませんが、画面の読み込み時間であれば快適な範囲内です。
20ミリ秒はページ内応答時間であれば十分高速ですが、『アニメーション』のフレームという観点では、60フレーム/秒に満たないため、若干の遅延を感じる可能性があります。

一言に画面の応答時間は『1秒』を基準にしましょう。のようなパフォーマンスの設定方法は、UXを損なう可能性があるため、『応答時間』だけを絶対の基準にするのは危険だなと感じました。

1秒あたりから違和感を感じ始める

『応答時間』を絶対の基準にするのは危険とは言いつつも、2つの指標を見る限り、1秒あたりでユーザーは何らかの違和感を感じ始めるようです。(もちろん場面やタスクによります。)

10秒を超えると作業なんてしていられない

そして、もう一つ重要な基準になるのは、10秒というラインです。
10秒を超えてしまえば、ユーザーの集中力は完全に切れて、イライラして作業どころではない。というのは2つの指標で共通しています。
(恐らくは私は10秒も待てません。6~7秒くらいでイライラしていると思います。)

まとめ

  • 『応答時間』の秒数だけを絶対の基準にしてパフォーマンスを設定するのは危険。
  • 『応答時間』とその時間がかかっている場面やタスクを合わせて考えるのが重要
  • 『応答時間』だけに限って言えば、1秒でユーザーは違和感を感じ始める。
  • 『応答時間』だけに限って言えば、10秒を超えればユーザーはいなくなる。

参考・引用資料