Быстрые фильтры в больших каталогах: как не убить базу и не потерять индексацию
Фильтр — самый нагруженный элемент каталога. Он одновременно решает две конфликтующие задачи: мгновенно отвечать пользователю и не плодить миллионы мусорных URL.
Почему фильтры тормозят
Классическая причина — характеристики хранятся вертикально в таблице «свойство-значение», и каждый выбранный фильтр добавляет ещё один JOIN. На пяти условиях запрос уходит в секунды, а при росте каталога — в десятки секунд.
Вторая причина — подсчёт общего количества результатов и счётчиков у каждого варианта фильтра. Полный COUNT по большой выборке нередко дороже, чем выборка самих товаров на первой странице.
Третья — сортировка по вычисляемому полю вроде итоговой цены со скидкой. Если её нельзя проиндексировать, база сортирует всю выборку целиком на каждый запрос.
Что делать со схемой данных
Денормализуйте характеристики, по которым фильтруют чаще всего, в отдельные колонки товара с индексами. Универсальность EAV-схемы удобна редактору, но платит за неё пользователь скоростью.
Составные индексы стройте под реальные комбинации фильтров, а не по одному полю на индекс. Порядок колонок в индексе имеет значение: сначала поля точного равенства, затем диапазон, затем сортировка.
Для каталогов, где фильтров десятки, а комбинаций сотни, вместо тюнинга SQL правильнее вынести поиск в поисковый движок с инвертированным индексом. Тогда фасеты и счётчики считаются за один запрос, а база остаётся источником истины.
Кеширование и счётчики
Результаты фильтрации кешируйте по нормализованному ключу: отсортированный набор параметров, страница, сортировка. Разный порядок параметров в URL не должен создавать разные ключи кеша.
Счётчики количества товаров у каждого варианта фильтра полезны, но дороги. Компромисс: считать их с небольшой задержкой обновления, а не в реальном времени, и скрывать варианты с нулевым результатом.
Инвалидация кеша привязывается к обновлению цен и остатков из учётной системы. При синхронизации каждые 10–15 минут разумно сбрасывать кеш выборочно по затронутым категориям, а не целиком.
URL, индексация и дубли
Для одного-двух популярных фильтров делайте отдельные ЧПУ-страницы вида /katalog/nasosy/pogruzhnye/, открытые к индексации, с собственными title, description и текстом. Это основной источник трафика по длинным запросам.
Все остальные комбинации оставляйте на GET-параметрах и закрывайте: canonical на базовую категорию плюс noindex, follow для многофакторных комбинаций. Без этого каталог генерирует бесконечное число URL и съедает краулинговый бюджет.
Сортировка и пагинация не должны создавать индексируемые дубли: canonical со страниц сортировки ведёт на базовую, а страницы пагинации имеют самоссылочный canonical и уникальный title с номером страницы.
Интерфейс и ощущение скорости
На мобильном фильтры открываются панелью снизу с кнопкой применения и счётчиком найденного. Мгновенное применение каждого чекбокса на 3G ощущается как зависание: пользователь ставит три галочки, а сеть отрабатывает три запроса.
Показывайте выбранные фильтры чипами над списком с возможностью снять по одному и кнопкой сброса всех. Пользователь, не понимающий, почему видит четыре товара, просто уходит.
Состояние фильтров обязано быть в URL, чтобы страница делилась ссылкой и переживала кнопку «назад». Для локальной аудитории с Telegram это особенно важно: подборку отправляют ссылкой в чат.
Диапазоны, приоритеты и измерения
Диапазон цены в сумах делайте с полями ввода, а не только ползунком: попасть ползунком в нужное значение на телефоне сложно, а суммы длинные. Применяйте значение с задержкой в несколько сотен миллисекунд после окончания ввода.
Порядок фильтров задавайте по частоте использования, а не по алфавиту. Первые два-три фильтра должны быть теми, которыми реально пользуются, а остальные — под сворачиванием.
Логируйте применяемые комбинации фильтров и пустые результаты. Частая комбинация без товаров — это либо пробел в ассортименте, либо кандидат на отдельную посадочную страницу.