web-dev-qa-db-ja.com

ライブ検索の応答時間

バックエンドチームに提供できるライブ検索機能の許容可能な応答時間に関する調査を探しています。

いくつかの定義：

  • ライブ検索：ユーザーが入力すると結果が自動的に絞り込まれます
  • 従来の検索：ユーザーは完全なクエリを入力してから、明示的に検索機能を呼び出します（ボタンを押すなど）。

もちろん、ライブ検索のideal応答時間は100ミリ秒未満であり、これは一般的に消費者向けのパブリックWebアプリで見られるものです。この種のパフォーマンスをバックエンドから得ることができると確信していれば、わざわざ質問することはありません。

私は何十年も生産されているレガシーシステムに支えられたB2Bアプリを使用しているので、今のところ100ms未満は問題外です。だから私はライブ検索を実現可能にする最大応答時間を求めています？ 200msで、あなたが失うことを知っています システムが瞬時に応答しているような錯覚 ですが、入力と結果のフィードバックループに干渉するほど遅いため、ライブ検索が使用できなくなるか、イライラします。ユーザーは従来の検索を好む傾向がありますか？ 400msはどうですか？制限は何ですか？ 1000msまで行くことはできますか？

単一の目標数では十分ではないと思います。応答時間は常に完全に同じになるとは限りませんが、おそらくベータ分布に適合します。

right skewed beta distribution

平均応答時間を指定した場合、応答の3/4が、その数をはるかに超えて、他の1/4ファンが望ましい範囲内にある可能性があります。一方、最大応答時間を指定した場合、1000のうち1つの長時間実行されているクエリは、テストの成功を損なう可能性があります。

したがって、私はバックエンドチームに2つのパフォーマンスパラメータを与えるつもりです。

average response time: <250ms
95% of responses: <1000ms

私は、それらの数値を洗練し、直感以上にそれらをバックアップするのに役立つ研究や情報を探しています。

searchresponse-time
1
Patrick McElhaney

要約すると、あなたが言及した記事では、 Website Response Times が言及されています：

3つの応答時間制限は、1993年に私がそれらについて書いたときと同じです（人的要因の先駆者による40年の研究に基づく）。

  • 0.1秒は、瞬間的な反応の感覚を与えます—つまり、結果それはユーザーではなく、コンピューターによって引き起こされたように感じます。このレベルの応答性は、直接操作の感覚をサポートするために不可欠です（直接操作は、ユーザーエンゲージメントとコントロールを向上させるための主要なGUIテクニックの1つです。
  • 1秒は、ユーザーの思考の流れをシームレスに保ちます。ユーザーは遅延を感じることができるため、コンピューターが結果を生成していることはわかりますが、全体的なエクスペリエンスを制御でき、コンピューターを待つのではなく自由に動いていると感じます。この程度の応答性は、良好なナビゲーションに必要です。 （...）

ミラー1968;カード他1991：

「0.1秒は、システムが瞬時に反応しているとユーザーに感じさせるための制限です。1.0秒は、ユーザーの思考の流れが中断されないようにするための制限です...」

リソース：

Nielsen、J.（1993）。応答時間：3つの重要な制限。 http://www.nngroup.com/articles/response-times-3-important-limits/

Nielsen、J.（1997）。スピードの必要性。 http://www.nngroup.com/articles/the-need-for-speed/

Nielsen、J.（2010）。 Webサイトの応答時間。 http://www.nngroup.com/articles/website-response-times/

したがって、検索の場合、ユーザーは100ミリ秒以下の応答時間を期待し、1秒以上経過しても提案が表示されないはずです。

あなたが考慮すべきことは、ライブ検索であり、表示結果は時々オートコンプリートと組み合わせることができるという事実であるので、それは違いであるはずであり、応答の最大時間が400msまたは900ms未満であるかどうか心配する必要はありません。このため、興味深い この質問 と受け入れられた応答を見つけるかもしれません。

リスト用のフィルターフォームがあります。フィールドの1つはテキスト検索フィールドです。ユーザーがフィールドに入力するとき、ユーザーが0.5秒（500ミリ秒）入力を停止するまで待ってから、検索を実行します。 （...）1秒間（1000ミリ秒）の遅延は長すぎるように見えますが、任意の値を選択するのではなく、遅延の長さについて何らかのコンセンサスがあるのではないかと考えていました。

私の結論は1秒が最大であるべきだということです。

1
Madalina Taina

自分が取り組んでいるソフトウェアプロジェクトについても、同様の仕様の問題がありました。開発チームは、ユーザーが文字を入力（または削除）した後に結果を返すまでの時間を指定する必要がありました。これは、オートコンプリート文字列が表示される速度ではなく、検索の実際の結果です。

私は少し異なる方法で問題に取り組みました。私がUXヒューリスティック（私が自分で定義したもの）は、ユーザーが検索文字列の次の文字を入力する前に結果を返す必要があるというものでした。つまり、ユーザーベースが入力する速度を見積もる必要がありました。

  • 60 wpmのトップエンド（特に、コーヒーを飲んだとき！）、から派生
    • 平均タイピング速度は〜35-40 wpmです。以下を参照してください https://en.wikipedia.org/wiki/Words_per_minute
    • ユーザーベースはエンジニアリングスタッフとテクニカルスタッフであり、一日の大部分をコンピューターを使用しているため、タイピングはもう少し慣れていると思います
    • 私自身を測定して、私は50 wpmあたりに来ます
  • Wordあたり平均5文字（英語）、次を参照： http://norvig.com/mayzner.html

これは、毎分300文字（スペースは含まない）、つまり毎秒5文字です。これにより、許容可能な応答時間は200msになります。

あなたの場合、あなたのユーザーベースに合うようにこのモデルのパラメーターを微調整することができます。このアプローチは、ベータ配布仕様の方法論における平均応答時間の良い値になると思います。

1
Matt Rozek