Разработка фильтрации товаров по параметрам для интернет-магазина

Разработка фильтрации товаров по параметрам для интернет-магазина

Фильтрация — один из главных инструментов навигации в каталоге. Пользователь с 500 ноутбуками в категории не будет листать страницы — он отфильтрует по бренду, RAM и диагонали. Плохая фильтрация теряет эти продажи. Хорошая фильтрация — это faceted search: доступные значения фильтров обновляются в зависимости от уже выбранных, и пользователь всегда знает, сколько товаров за каждым значением.

Типы фильтров

Faceted search с SQL

Самый простой подход — фильтрация через PostgreSQL. Работает до ~100 000 товаров при правильной индексации.

-- Основной запрос с фильтрами
SELECT p.* FROM products p
WHERE p.category_id = :cat
  AND (:brands IS NULL OR p.brand = ANY(:brands::text[]))
  AND (:price_min IS NULL OR p.price >= :price_min)
  AND (:price_max IS NULL OR p.price <= :price_max)
  AND (:in_stock IS NULL OR p.stock > 0)
ORDER BY p.sort_order
LIMIT 48 OFFSET :offset;

-- Агрегации для счётчиков (отдельный запрос на каждый фильтр)
SELECT brand, COUNT(*) FROM products p
WHERE p.category_id = :cat
  -- Все фильтры КРОМЕ brand
  AND (:price_min IS NULL OR p.price >= :price_min)
GROUP BY brand;

Проблема SQL-подхода: для корректных счётчиков нужен отдельный запрос агрегации для каждого фильтра, исключая этот фильтр из условий. При 10 активных фильтрах — 10 дополнительных запросов. На реальной нагрузке это не масштабируется.

Faceted search с Elasticsearch

Elasticsearch решает задачу за один запрос через aggregations:

{
  "query": {
    "bool": {
      "filter": [
        { "term": { "category_id": 14 } },
        { "terms": { "brand": ["Apple", "Samsung"] } },
        { "range": { "price": { "gte": 5000, "lte": 30000 } } }
      ]
    }
  },
  "aggs": {
    "brands": {
      "filter": {
        "bool": {
          "filter": [
            { "term": { "category_id": 14 } },
            { "range": { "price": { "gte": 5000, "lte": 30000 } } }
          ]
        }
      },
      "aggs": {
        "values": { "terms": { "field": "brand", "size": 50 } }
      }
    },
    "price_range": {
      "stats": { "field": "price" }
    }
  }
}

Каждая агрегация (brands, ram, screen_size) использует фильтр без своего собственного условия — это и есть faceted search. Один запрос возвращает и товары, и все счётчики для всех фильтров.

URL-схема для фильтров

URL должен отражать состояние фильтров для шаринга и SEO:

/noutbuki?brand=apple,samsung&ram=16&price_min=50000&price_max=100000&sort=price_asc

При изменении фильтра — pushState или replaceState без перезагрузки страницы. При прямом входе по URL — инициализация состояния фильтров из параметров.

SEO-подход: популярные комбинации фильтров (бренд + категория) оформляются как отдельные статичные страницы с уникальным контентом и canonical. Страницы с редкими комбинациями — <meta name="robots" content="noindex">.

Клиентская реализация

Состояние фильтров хранится в URL (source of truth) и зеркалируется в React state:

type FilterState = {
  brands: string[];
  ram: number | null;
  priceMin: number | null;
  priceMax: number | null;
  inStock: boolean;
  sort: 'price_asc' | 'price_desc' | 'popularity' | 'rating';
};

function useFilters() {
  const [searchParams, setSearchParams] = useSearchParams();

  const filters = useMemo(() => parseFilters(searchParams), [searchParams]);

  const setFilter = (key: keyof FilterState, value: unknown) => {
    const next = { ...filters, [key]: value };
    setSearchParams(buildParams(next), { replace: true });
  };

  return { filters, setFilter };
}

При каждом изменении фильтра — debounce 300ms, затем запрос к API. Результаты обновляются без перезагрузки страницы.

Ценовой слайдер

Компонент диапазона цен — отдельная задача. Требования:

• Два handle (min и max), которые не могут пересечься
• При вводе с клавиатуры — валидация и clamp
• Гистограмма распределения цен за слайдером (показывает, где сконцентрированы товары)

Гистограмма: Elasticsearch aggregation histogram с interval = (max_price - min_price) / 20. Отображается через SVG path или tiny bar chart.

Готовые компоненты: @radix-ui/react-slider, rc-slider, noUiSlider. Radix-вариант предпочтителен при Tailwind-стеке.

Оптимизация производительности

Кеш агрегаций: результаты подсчёта фасетов меняются не при каждом запросе. Кешируем агрегации для категории с типичным набором фильтров в Redis на 5–10 минут. При обновлении товара инвалидируем кеш категории.

Индексы PostgreSQL:

-- Составной индекс для типичного запроса
CREATE INDEX ON products (category_id, brand, price)
  WHERE status = 'active';

-- GIN-индекс для JSONB-атрибутов
CREATE INDEX ON products USING GIN (attributes);

Lazy loading фасетов: показываем первые 5–7 значений, кнопка «Показать все» подгружает остальные отдельным запросом.

Мобильная адаптация

На мобайле фильтры скрыты за кнопкой «Фильтры» → открывается нижний drawer (bottom sheet) на весь экран. Внутри — те же компоненты, но с увеличенными touch targets. Кнопка «Применить» фиксирована внизу. При применении drawer закрывается, список обновляется.

Сроки

• Базовая фильтрация (SQL, чекбоксы по 3–4 атрибутам, диапазон цен): 1–2 недели
• Faceted search на Elasticsearch (динамические счётчики, все типы фильтров, URL-синхронизация): 3–4 недели
• Добавление гистограммы цен и кеширования агрегаций: +1 неделя

Выбор между SQL и Elasticsearch определяется размером каталога. До 50 000 товаров хорошо спроектированный SQL справится. Выше — Elasticsearch даёт качественную разницу в скорости и богатстве фасетов.