Зачем нужны debounce и throttle в интерфейсах

Некоторые события DOM происходят с чрезвычайно высокой частотой. Событие keypress происходит при каждом нажатии клавиши. Событие scroll происходит десятки раз в секунду во время прокрутки. Событие resize происходит непрерывно, пока пользователь перетаскивает границу окна. Обработка каждого события по отдельности может перегрузить и браузер, и сервер.

Если обработчик нажатия клавиш выполняет сетевой запрос при каждом нажатии, пользователь, набирающий «хуки React» (11 символов), создаёт 11 сетевых запросов, большинство из которых относится к неполным поисковым запросам. Аналогично, обновление анимации параллакса на каждом пикселе прокрутки приводит к сотням повторных рендерингов React в секунду. Это расходует CPU, сеть и заряд батареи.

Отложенный вызов задерживает выполнение, пока событие не перестанет срабатывать в течение заданного периода. Если пользователь продолжает печатать, таймер сбрасывается после каждого нажатия клавиши. Только после N миллисекунд тишины обработчик наконец выполнится один раз. Отложенный вызов отвечает на вопрос: «запустить это после того, как пользователь закончит действие».

Ограничение частоты допускает выполнение не чаще одного раза за интервал времени, независимо от количества происходящих событий. Если пользователь быстро прокручивает страницу, ограничение в 100 мс гарантирует, что обработчик будет выполняться не более 10 раз в секунду. Ограничение частоты отвечает на вопрос: «запускать это регулярно, но не чаще одного раза в N мс».

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

Ограничение частоты подходит, когда во время непрерывной активности нужны регулярные обновления. Классические случаи: обработчик положения прокрутки (обновление индикатора прогресса чтения или закреплённого заголовка с частотой не более 30 кадров/с), отслеживание перемещения мыши (запись положения курсора для аналитики) и обработчики событий перетаскивания (плавное обновление положения перемещаемого элемента без лишней нагрузки).

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

Lodash предоставляет _.debounce(fn, wait) и _.throttle(fn, wait) с параметрами для поведения при первом и последнем срабатывании. Возвращаемая функция имеет метод .cancel() для отмены ожидающего вызова и метод .flush() для его немедленного выполнения. В React их следует оборачивать в useRef, чтобы избежать создания заново при повторном рендеринге.

Даже 50 дополнительных повторных рендерингов React в секунду из-за обработчика прокрутки без ограничения частоты могут заметно загрузить CPU, особенно на недорогих мобильных устройствах. Бюджет кадра в 16 мс (60 кадров/с) означает, что каждый повторный рендеринг должен завершаться менее чем за 16 миллисекунд, чтобы избежать пропущенных кадров. Отложенный вызов и ограничение частоты — ваша первая линия защиты от проблем с частотой кадров.

Не всем обработчикам событий с высокой частотой нужен отложенный вызов. Если обработчик лишь считывает значение, не обновляя состояние и не выполняя сетевые запросы, — например, записывает последнее положение мыши в объект ссылки, — отложенный вызов не требуется. Ограничивайте частоту только у обработчиков, запускающих затратные операции: обновление состояния, сетевые запросы или измерения DOM.

При размонтировании компонента любой ожидающий отложенный вызов следует отменить, чтобы предотвратить обновление состояния после размонтирования. Если вы используете useRef для хранения отложенной функции, вызовите debouncedFn.cancel() в функции очистки useEffect. Отложенные функции Lodash предоставляют этот метод именно для такой цели.

Какой приём следует использовать, чтобы выполнить сетевой запрос, когда пользователь перестаёт печатать в поле поиска?

События с высокой частотой, такие как keypress, scroll и resize, могут вызывать проблемы с производительностью, если обработчики выполняются при каждом событии. Отложенный вызов ждёт тишины и лучше всего подходит для полей поиска и обработчиков изменения размера. Ограничение частоты уменьшает частоту выполнения и лучше всего подходит для прокрутки и перетаскивания. Используйте реализации Lodash, сохранённые в объектах ссылок, и всегда отменяйте их при размонтировании компонента.