web-dev-qa-db-ja.com

テキスト入力のデバウンスの長さ

次のような簡単な例があるとしましょう。

<input id="filter" type="text" />
<script>

    function reload() {
     // get data via ajax
    }

    $('#filter').change($.debounce(250,reload));
</script>

私たちがしているのは、ユーザーが入力にテキストを入力している間にreloadの呼び出し回数を減らすために、小さな遅延を導入することです。

今、私はこれがケースバイケースの基礎に依存することを理解していますが、平均（または多分それは最低公分母でなければならない）タイピング/相互作用速度を考えると、デバウンス遅延の長さの受け入れられた知恵があります。私は通常、適切に「感じる」まで値をいじりますが、一般的なユーザーを代表することはできません。誰もこれに関する研究をしましたか？

javascriptuser-interfaceuser-experience
23
Sam Shiles

あなたがほのめかしたように、答えはいくつかの要因に依存します-それらのすべてが主観的ではありません。

一般に、デバウンス操作を使用する理由は、次の2つの目的のいずれかを持つと要約できます。

  1. 動的なインタラクティブ要素を提供するコストを削減します（コストは計算、IO、ネットワーク、または待ち時間であり、クライアントまたはサーバーによって決定される場合があります）。
  2. 視覚的な「ノイズ」を減らして、ユーザーが忙しいときにページの更新でユーザーの注意をそらさないようにします。

反応時間

念頭に置いておくべき重要な数値の1つは250ミリ秒です。これは、人間の（おおよそ）反応時間の中央値を表しており、一般にサイトの応答性を保つためにユーザーインターフェイスの更新を完了する必要がある適切な上限です。人間の反応時間に関する詳細情報を表示できます こちら 。

前者の場合、正確なデバウンス間隔は、操作のコストが両当事者（クライアントとサーバー）にどの程度かかるかによって異なります。 AJAX呼び出しのエンドツーエンドの応答時間が100ミリ秒の場合、デバウンスを150ミリ秒に設定して、その250ミリ秒の応答性しきい値を維持するのが理にかなっています。

一方、コールの実行に通常4000ミリ秒かかる場合は、実際のコールに長いデバウンスを設定し、代わりに第1層のデバウンスを使用してロードインジケーターを表示することをお勧めします（ロードインジケーターが不明瞭にならない場合）テキスト入力）。

$('#filter').change($.debounce(250, show_loading)); $('#filter').change($.debounce(2000, reload));

バックエンド容量

バックエンドでのこれらのリクエストのパフォーマンスコストに留意することも重要です。この場合、 平均タイピング速度 （約44ワード/分、または約200文字/分）とユーザーベースサイズとバックエンド容量の知識の組み合わせにより、デバウンス値を選択できます。バックエンドの負荷を管理しやすくします。

例：1秒あたり10個のリクエストを処理できる単一のバックエンドと30のアクティブユーザーベースのピーク（このサービスを使用）がある場合、1秒あたり10個のリクエストを超えないようにデバウンス期間を選択する必要があります（理想的にはエラー）。この場合、ユーザーごとに1秒あたり1つの入力を処理するために必要な容量の33.3％があるため、理想的には3秒ごとにユーザーごとに最大1つのリクエストを処理し、3000msデバウンス期間。

フロントエンドのパフォーマンス

最後に留意すべき点は、クライアント側での処理のコストです。移動するデータの量とUI更新の複雑さに応じて、これはごくわずかまたは重要です。試して確認したいことの1つは、ユーザーインターフェイスがユーザー入力に応答し続けることです。これは必ずしも反応できる必要があるという意味ではありませんが、ユーザーが操作している間は、迅速に反応する必要があります（ここでは一般に60FPSが目標です）。

この場合、ユーザーインターフェイスとの対話中にユーザーインターフェイスが遅くなったり応答しなくなったりするのを防ぐレートでデバウンスを行うことが目的です。繰り返しになりますが、統計はこの図を導き出すための良い方法ですが、入力のタイプが異なれば完了するまでに時間がかかることに注意してください。

たとえば、短い単語の文を転写することは、一般に、長くて複雑な単一の単語を入力するよりもはるかに高速です。同様に、ユーザーが入力内容について考える必要がある場合は、入力が遅くなる傾向があります。同じことは、特殊文字または句読点の使用にも当てはまります。

主観的回答

実際には、100ms取得が非常に速く、パフォーマンスにほとんど影響を与えないデータの場合5000msより高価なもの。

後者の場合、短い低コストのデバウンス期間を組み合わせてユーザーにフィードバックを提供し、実際の計算作業の期間を長くすると、ユーザーエクスペリエンスと無駄な操作のパフォーマンスコストのバランスが取れやすくなります。

これらの値を選択する際に心に留めておくべき重要なことの1つは、毎日キーボードを操作する人として、おそらくほとんどのユーザーベースよりも速く入力することです。これは、私にとってスムーズで自然なことは、タイプが遅い人にとって不快なことを意味する可能性があるため、ユーザーテストを行うか、（より良い）メトリックを収集し、それらを使用してインターフェイスを調整することをお勧めします。

41
Benjamin Pannell