Поиск, который думает секунду, воспринимается как сломанный. Особенно это заметно в подсказках: они обновляются на каждый введённый символ, и задержка превращает набор запроса в ожидание. Разбираем, откуда берутся миллисекунды и где они теряются.
Какая задержка заметна
Ориентиры, проверенные практикой интерфейсов:
| Задержка | Ощущение |
|---|---|
| до 100 мс | мгновенно |
| 100–300 мс | заметно, но приемлемо |
| 300 мс – 1 с | ощутимая пауза |
| больше 1 с | «завис» |
Для страницы результатов приемлемы первые две строки. Для подсказок при вводе — только первая: пока человек печатает, ответ должен приходить быстрее, чем он нажмёт следующую клавишу.
Откуда берётся задержка
Обращение к внешнему сервису
Самая частая и самая дорогая причина. Если превращение запроса в понятный поиску вид требует обращения наружу, к задержке добавляется сетевой путь туда и обратно — и это в лучшем случае десятки миллисекунд, а обычно больше. Плюс вы платите за каждое нажатие клавиши.
Локальные вычисления убирают этот пункт целиком.
Подсчёт фильтров по всей базе
Фасетные фильтры считаются по текущей выдаче — и наивная реализация честно проходит по всем найденным товарам, чтобы собрать значения. На выдаче из десяти тысяч позиций это дороже самого поиска.
Решается предварительно построенными структурами: количество товаров по каждому значению известно заранее и пересчитывается при обновлении каталога, а не при каждом запросе.
Сортировка всего результата
Найдено двадцать тысяч товаров, показывается двадцать. Сортировать при этом нужно не всё: достаточно найти двадцать лучших, а не упорядочить весь список.
Отсутствие индекса по характеристикам
Поиск по свойствам, реализованный перебором, работает приемлемо на тысяче товаров и перестаёт — на сотне тысяч.
Медленная база под нагрузкой
Часто оказывается, что поиск сам по себе быстрый, но конкурирует за ресурсы с витриной магазина. Разделение нагрузки решает это без переписывания алгоритмов.
Что не является причиной
Размер каталога сам по себе. Правильно построенный индекс на 100 000 товаров работает почти так же, как на 10 000: время растёт не пропорционально числу позиций. Если при росте каталога вдесятеро поиск замедлился вдесятеро — проблема в устройстве, а не в объёме.
Количество полей. Индексация характеристик наравне с названием увеличивает индекс, но не время ответа.
Как мерить
Не «на глаз» и не по ощущениям на своём компьютере рядом с сервером.
- Замеряйте время ответа на сервере отдельно от времени отрисовки в браузере. Это разные вещи, и лечатся они по-разному.
- Смотрите не среднее, а верхние проценты. Среднее время в 40 мс при том, что каждый двадцатый запрос отвечает секунду, — плохой поиск: именно эти запросы и запоминаются.
- Меряйте на настоящих запросах, выгруженных из статистики, а не на слове «дрель». Реальные запросы длиннее, содержат ошибки и числа.
- Меряйте под нагрузкой, а не в тишине.
Практический ориентир
Для каталога в сотню тысяч позиций поиск вместе с группировкой по категориям укладывается в десятки миллисекунд — при условии, что вычисления идут локально и индекс построен заранее. Это не предел возможностей, а нормальное рабочее состояние.
Если ваши числа заметно хуже, порядок разбора такой: сначала проверить, нет ли обращений к внешним сервисам в цепочке запроса; затем — как считаются фильтры; затем — есть ли индекс по тем полям, по которым идёт поиск.
Коротко
- Для подсказок при вводе приемлемая задержка — до сотни миллисекунд.
- Главный источник задержки — обращения к внешним сервисам на каждый запрос.
- Фильтры нужно считать по заранее построенным структурам, а не перебором выдачи.
- Размер каталога сам по себе не причина: правильный индекс масштабируется хорошо.
- Мерить нужно верхние проценты времени ответа на настоящих запросах и под нагрузкой.