Как долго вы должны debounce ввода текста

допустим у нас есть простой пример как ниже.

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

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

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

мы вводим небольшую задержку, чтобы уменьшить количество вызовов до reload пока пользователь вводит текст во вход.

теперь я понимаю, что это будет зависеть от случая к случаю, но есть ли принятая мудрость о том, как долго должна быть задержка дебоунса, учитывая среднюю (или, может быть, это должен быть самый низкий общий знаменатель) скорость ввода/взаимодействия. Я вообще просто играю вокруг со значением, пока он не" чувствует " себя правильно, но я не могу представлять типичного пользователя. Кто-нибудь проводил исследования?

14
javascript user-experience user-interface

1 ответов

как вы намекнули, ответ зависит от ряда факторов - не все из них субъективны.

В общем, причина использования операции debounce может быть суммирована как имеющая одну из двух целей:

  1. снижение стоимости предоставления динамических интерактивных элементов (где стоимость может быть вычислительной, ввода-вывода, сети или задержки и может быть продиктована клиентом или сервером).
  2. уменьшение визуального "шума" для избежания отвлечь потребителя с страницей обновления пока они заняты.

Время Реакции

одним из важных чисел, чтобы иметь в виду, является 250ms - это представляет собой (примерно) медианное время реакции человека и, как правило, хорошая верхняя граница, в пределах которой вы должны завершить любые обновления пользовательского интерфейса, чтобы ваш сайт чувствовал себя отзывчивым. Вы можете просмотреть дополнительную информацию о времени реакции человека здесь.

в первом случае точный интервал debounce будет зависит от того, какова стоимость операции для обеих сторон (клиента и сервера). Если ваш вызов AJAX имеет время ответа от конца до конца 100 мс, то может иметь смысл установить ваш debounce на 150 мс, чтобы оставаться в пределах этого порога отзывчивости 250 мс.

С другой стороны, если ваш вызов обычно занимает 4000ms для запуска, вам может быть лучше установить более длинный debounce на фактическом вызове и вместо этого использовать debounce первого уровня, чтобы показать индикатор загрузки (предполагая, что ваша загрузка индикатор не скрывает ваш ввод текста).

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

Бэкэнд Емкостью

также важно иметь в виду стоимость производительности этих запросов на вашем бэкэнде. В этом случае комбинация средняя скорость набора текста (около 44 слов в минуту, или примерно 200 символов в минуту) и знание размера базы пользователей и емкости бэкэнда может позволить вам выбрать значение debounce, которое сохраняет нагрузку на бэкэнд легкоуправляемый.

например: если у вас есть один сервер, способный обрабатывать 10 запросов в секунду и Пиковую активную пользовательскую базу 30 (используя эту услугу), вы должны выбрать период дебоунса, чтобы избежать превышения 10 запросов в секунду (в идеале с погрешностью). В этом случае у нас есть 33,3% емкости, необходимой для обработки одного ввода на пользователя в секунду, поэтому мы идеально будем обслуживать не более одного запроса на пользователя каждые 3 секунды, давая нам наш 3000ms debounce период.

Производительность Фронтэнда

последний аспект, который нужно иметь в виду, - это стоимость обработки на стороне клиента. В зависимости от объема перемещаемых данных и сложности обновлений пользовательского интерфейса это может быть незначительным или значительным. Одна вещь, вы хотите попробовать и убедиться, что ваш пользовательский интерфейс остается отзывчивым на действия пользователя. Это не обязательно означает, что он всегда должен быть в состоянии реагировать, однако, пока пользователь взаимодействует с ним, он должен быстро реагировать на них (60FPS, как правило, является целью здесь).

в этом случае ваша цель должна заключаться в том, чтобы дебютировать со скоростью, которая предотвращает вялость или невосприимчивость пользовательского интерфейса во время взаимодействия с ним. Опять же, статистика-хороший способ получить эту цифру, но имейте в виду, что для разных типов ввода требуется разное количество времени.

например, транскрибирование предложения коротких слов, как правило, намного быстрее чем вводить одно длинное и сложное слово. Аналогично, если пользователь должен думать о том, что они вводят, они будут иметь тенденцию вводить медленнее. То же самое относится и к использованию специальных знаков или знаков препинания.

Субъективный Ответ

на практике, я использовал периоды дребезга от 100ms для данных, которые исключительно быстро извлекаются и очень мало влияют на производительность до 5000ms для вещей, которые являются более дорогостоящими.

In в последнем случае спаривание короткого, недорогого периода дебоунса, чтобы представить пользователю обратную связь, и более длительный период для фактической вычислительной работы, как правило, обеспечивает хороший баланс между пользовательским опытом и стоимостью производительности потраченных впустую операций.

одна примечательная вещь, которую я стараюсь иметь в виду при выборе этих значений, заключается в том, что, как человек, который работает с клавиатурой каждый день, я, вероятно, печатаю быстрее, чем большинство моих пользователей. Это может значить что вещи которые чувствуют ровными и естественными к меня раздражает тот, кто печатает медленнее, поэтому неплохо провести тестирование пользователей или (еще лучше) собрать метрики и использовать их для настройки вашего интерфейса.

22