mtx2s’s blog

エンジニアリングをエンジニアリングする。

「機敏なユーザー体験」を実現するUIに求められる応答時間

機敏(snappy)なユーザー体験は、魅力的(glamorous)なユーザー体験に優る」とは、ヤコブ・ニールセン(Jakob Nielsen)の言葉だ。瞬時に起動し(あるいは表示され)、インタラクションに遅延を感じさせないアプリケーションは、いちユーザーとして使っていて本当に気持ちが良い。逆に、何をするにも「遅い」と感じさせるものもある。そのようなアプリケーションは、使うたびにうんざりするし、特別な理由がない限り使いたくないものだ。

そうであればこそ、ソフトウェアエンジニアはユーザインタフェース(UI)の応答時間に注意を払うべきだろう。それは、優れた体験を生み出してユーザーの離脱や離反を防止する効果が得られるだけではない。ビジネス価値向上に対し、エンジニアがイニシアチブを取れる数少ない対象の1つでもあるのだ。それに加え、そもそもエンジニアにとってパフォーマンスチューニングというものは、何であれ成功すれば達成感が得られるものだ。つまりUIの応答時間改善とは、ユーザー、ビジネス、エンジニアのいずれにとっても価値ある取り組みと言えるだろう。

では、「機敏(snappy)」と呼べる応答時間とは、どのように定義できるのだろうか。これが、本記事のテーマだ。

3つの時間制限

ヤコブ・ニールセンは、アプリケーションのパフォーマンスについて、0.1秒1.0秒10秒という3つの時間制限を用いて説明している。

0.1秒以内のフィードバックは、UIオブジェクトに対するユーザーの直接的な操作への応答としての限界点となる。これを超えると、ユーザーが遅延を感じるようになるからだ。

しかし、1.0秒以内であればまだ許容範囲だ。ユーザーは遅延を感じるものの、待たされているとまでは感じない。これが1.0秒を超えると、ユーザーは待たされていると感じるようになる。

それでも10秒以内であれば、ユーザーは引き続きタスクに注意を向け続けるが、10秒を超えても応答が無ければ、その注意も別のことに向け始めてしまう。最終的には、ユーザーは待つことをあきらめ、離脱してしまうかもしれないというのだ。

UIの遅延を感じさせない応答時間

まず0.1秒という時間制限であるが、wev.devの記事では、アルベール・ミショット(Albert Michotte)の研究に触れている。そこでの実験では、スクリーンに映し出された物体Aが移動し、静止している別の物体Bに接触した時、Bが0.1秒以内に動き出せば、実験の被験者は、Aの衝突がBの動作を引き起こしたという印象を受けるという結果になった。この遅延が0.2秒以内であれば、そのような印象を持つ被験者はまだ存在する。しかし、遅延が0.2秒を超えると、Bの動作はAによって引き起こされたという印象を持たないようだ。スチュアート・カード(Stuart K. Card)らによる "The information visualizer, an information workspace" でも、知覚処理(perceptual processing)を0.1秒と定義しているが、おそらくアルベール・ミショットの実験結果を参考にしたものだろう。

ロバート・ミラー(Robert B. Miller)の "Response time in man-computer conversational transactions" では、「キーの押下」や「文字の選択」といったユーザーの直接的な制御操作に対する反応時間の制限を0.1秒以内、あるいは0.1秒から0.2秒以下としている。その上で、ユーザーの熟練度によっては、この0.1秒から0.2秒の遅延を「遅い」と感じる可能性にも触れている。その例として挙げられているのは、機械式パイプオルガン奏者の訓練だ。彼らは、打鍵から音が鳴るまでの0.1秒から0.2秒の遅延に適応して演奏できるよう学ぶそうだ。

GoogleによるCore Web Vitals(CWV)の定義で該当するのはFID(First Input Delay)だろう。FIDとは、「ユーザーが最初にページを操作したとき (リンクをクリックしたり、ボタンをタップしたり、JavaScript を使用して実装されたカスタム コントロールを使用したりしたとき) から、その操作に応じてブラウザーが実際にイベント ハンドラーの処理を開始するまでの時間」のことだ。CWVでは、75パーセンタイルの応答時間0.1秒以下のページを "GOOD" とし、0.1秒から0.2秒のページを "NEEDS IMPROVEMENT" としている。ここでの0.1秒という閾値は、Google Chromeの匿名化された集計結果に基づいて定義されている。Chrome UX Report(CrUX)に貯められたそれらのデータの75パーセンタイル以上のオリジンが、0.1秒以内で応答していたのだ(スマートホン:78%, デスクトップ:99%超)。

これらを踏まえると、UIオブジェクトの直接的な操作に対する応答時間としては、0.1秒以下という制限が妥当そうだ。0.2秒以下であっても許容範囲であるが、人によっては遅延を感じる可能性を考慮すべきだろう。

「待たされている」と感じさせない応答時間

次に、1.0秒以内という時間制限についてみてみると、上述したスチュアート・カードらの文献では、即時反応(immediate response)を1秒と定義している。この時間を超えてあまりに長くなると、ユーザーは応答を待つのに飽きてしまうとされている。この定義はアレン・ニューウェル(Allen Newell)の書籍 "Unified theories of cognition(認知の統一理論)" からの引用だ。web.devの記事によると、そこでの定義は即時反応を0.3秒から3秒としている。

ロバート・ミラーは先の文献で、「人間がマシンコミュニケーションで行える(あるいは行おうとする)タスクは、応答遅延が2秒を超え、さらに1秒程度延長される可能性があると、その性格を大きく変えてしまう」と述べている。

CWVでの定義はどうなっているかと言えば、LCP(Largest Contentful Paint)2.5秒以下を "GOOD" とし、2.5秒から4.0秒を "NEEDS IMPROVEMENT" としている。これもFIDと同様、CrUXのデータに基づいて定義されている。ちなみにLCPとは、「ビューポート内に表示される最も大きい画像またはテキストブロックのレンダリング時間」としている。

ヤコブ・ニールセンの定義から分かるように、ここでは人間がコンピュータに「待たされている」と感じるか否かを分ける応答時間の境界が焦点となる。ここでの参考文献を総合すると、1秒以内であれば十分で、2秒から3秒だと、待たされていると感じる可能性が高くなるということだろう。

ユーザーがタスクを成功させる応答時間

最後に、10秒以内という時間制限についてだが、スチュアート・カードはこれを単位タスク(unit task)の要件としている。ユーザーによる何らかの簡単なタスク行為を10秒以内に完了させられることを目指すという目標値だ。ヤコブ・ニールセンによれば、これは、タスク行為中の人間の短期記憶に保存された情報の減衰と関連している。10秒よりさらに時間を要してようやくシステムから応答が返されても、ユーザーは、中断していたタスクを再開することが困難になり、タスクを成功させる可能性が低下する。それどころか、多くの場合、10秒の遅延はユーザーを離脱させてしまうと言うのだ。CWVの背景にある調査でも、3秒間隔で様々な遅延をテストした結果には、9秒から12秒の遅延で満足度が低下し、12秒の遅延で戻る意思が低下したとある。

ロバート・ミラーは、複雑な問い合わせに対する図やグラフでの応答を、2秒以内に開始して10秒以内に完了する必要性を述べている。ただし、同様の複雑な問い合わせであっても、表形式での応答であれば4秒以内としているため、この制限時間内に行われると想定される処理の多くは描画によるものと考えられる。当該文献が公開された当時と比べ、現在のコンピュータは遥かに性能が向上しているので、この閾値はそのまま採用すべきでないだろう。しかし、これはユーザーによる思考の連続性を維持することを目的に定義された時間制限とされているため、本質はそこにあると捉えておけば良さそうだ。

機敏(snappy)なユーザー体験とは

以上を踏まえた上で、「機敏(snappy)なユーザー体験」と呼べる応答時間について自組織に向けて定義してみるなら次のようになるだろうか。なお、私自身の理解度がまだ十分ではないためか、多少違和感は残る。

  • UIオブジェクトの応答時間:0.1秒から0.2秒以内 - フロントエンドのみで処理できるような、UIオブジェクトの操作に対する反応。許容範囲は0.2秒だが、それでは「遅い」と感じるユーザーも存在するため、0.1秒以内が望ましい。
  • 画面表示の切り替え:1秒から2秒以内 - ネットワークを介したバックエンドとの通信も必要とするような画面の切り替え。2.5秒以内でも良い。ユーザーやコンテキストによっては、3秒だと「遅い」と感じさせてしまうこともある。10秒を超えるとユーザーが離脱する可能性がある。
  • 処理コストの高い問い合わせへの応答:2秒から10秒以内 - ビジネス向けの分析機能や、複雑な条件を組み合わせた問い合わせへの応答など。10秒を超える応答時間は、調査や分析を目的としたユーザーのタスク遂行の阻害となる。

ソフトウェアプロダクトにとって、「魅力的(glamorous)なユーザー体験」の実現が重要な課題であることは間違いない。一方で「機敏なユーザー体験」は、「魅力的なユーザー体験」と違い、その実現に求められるものが何であるかが明らかである。それはスピードだ。やるべきことは、迅速に応答を返すことでしかない。その実現難易度が高くとも、迷わず進めることが可能であるからこそ、継続的に取り組みたい重要な課題に位置づけられるだろう。そして、その価値がユーザーのみならずビジネスに及ぶことは、CWVのケーススタディからも期待が持てる。何より、エンジニアにとっても達成感が得られる取り組みになるのではないだろうか。