В интернет-магазине с тысячами товаров из разных регионов обычный список городов перестаёт работать. Пользователь ждёт 5 секунд загрузки, фильтр сбрасывается после выбора, а менеджеры не могут быстро найти товары местных поставщиков. Мы решаем эту задачу: разрабатываем иерархический фильтр по географии с автодополнением и тегированным кэшированием. Оптимизация запросов даёт прирост скорости до 3 раз даже при 500+ городах. В основе решения — инфоблоки и HL-блоки Битрикс, события для синхронизации и агенты для обновления данных. Такая оптимизация снижает затраты на серверное оборудование и ускоряет окупаемость инвестиций в разработку.
Основные проблемы и их решение
Медленная загрузка при большом списке городов. Если городов больше 50, выпадающий список
Отсутствие иерархии регион → город. Пользователь из Татарстана сначала выбирает регион, затем город — без этого фильтром сложно пользоваться. Мы реализуем двухуровневый выбор: регион загружает города асинхронно через JSON-API.
Интеграция с 1С. Города приходят из справочника 1С в CommerceML, и их нужно синхронизировать с инфоблоком. Мы создаём агент с тегированным кэшированием, который обновляет список городов раз в сутки без потери производительности.
Из нашей практики: кейс сети фитнес-клубов
Из нашей практики: для сети фитнес-клубов (клиент из сферы спорта, 120 городов, 800 товаров) мы выбрали инфоблок городов с полями: UF_COORDINATES, UF_TIMEZONE, UF_REGION_CODE. Товары привязывались через множественное свойство «Привязка к элементам инфоблока». Код компонента фильтра использует ORM Bitrix\Iblock\ElementTable с фильтром по PROPERTY_CITY и тегированным кэшем:
use Bitrix\Iblock\Elements\ElementCatalogTable;
use Bitrix\Main\Entity\ReferenceField;
$cache = new CPHPCache();
$cacheTime = 3600;
$cacheId = 'geo_filter_' . md5(serialize($_GET));
$cachePath = '/geo_filter';
if ($cache->InitCache($cacheTime, $cacheId, $cachePath)) {
$result = $cache->GetVars();
} else {
$filter = ['IBLOCK_ID' => IBLOCK_CATALOG_ID];
if (!empty($_GET['region'])) {
$regionCode = htmlspecialchars($_GET['region']);
$cityIds = getCitiesByRegion($regionCode);
$filter['PROPERTY_CITY'] = $cityIds;
}
$result = ElementCatalogTable::getList([
'filter' => $filter,
'select' => ['ID', 'NAME', 'PRICE_'],
'cache' => ['ttl' => 3600]
])->fetchAll();
$cache->StartDataCache();
$cache->EndDataCache($result);
}
Для автодополнения endpoint возвращает города по частичному совпадению:
// /catalog/filter/geo-suggest/?q=мо
$q = trim($_GET['q']);
if (mb_strlen($q) < 2) die('[]');
$result = CityTable::getList([
'filter' => ['%NAME' => $q],
'select' => ['CODE', 'NAME'],
'limit' => 10
])->fetchAll();
header('Content-Type: application/json');
echo json_encode($result);
Иерархический фильтр в 3 раза быстрее плоского списка при 200+ городах за счёт асинхронной загрузки. Все запросы кэшируются, нагрузка на сервер минимальна.
Как ускорить геофильтрацию?
Основные методы: тегированное кэширование, индексация полей в базе, использование ORM вместо GetList, асинхронная загрузка городов. Для больших каталогов (>10 000 элементов) обязательно добавьте индекс на свойство с кодом города и включите кэширование компонента.
Почему стоит выбрать иерархический фильтр?
| Критерий | Плоский список | Иерархический регион→город |
|---|---|---|
| Время загрузки страницы | ~200 мс (50 городов) | ~80 мс (кэш) |
| Удобство для пользователя | Листать длинный список | Выбрать регион → город |
| Количество городов | до 50 | 500+ без потери скорости |
| Интеграция с 1С | Ручная синхронизация | Автоматическая через агент |
Сравнение способов хранения геоданных
| Способ | Гибкость | Производительность | Синхронизация с 1С |
|---|---|---|---|
| Инфоблок городов | Высокая | Средняя (нужны индексы) | Автоматическая |
sale.location |
Средняя | Высокая (встроенное кэширование) | Ручная (через API) |
| Свойство-список | Низкая | Высокая (мало городов) | Нет |
Процесс работы
- Аналитика — разбираем текущий каталог, определяем объём данных и источники географии (1С, CSV, API).
- Проектирование — выбираем способ хранения (инфоблок,
sale.location, свойства), проектируем схему БД и индексы. - Реализация — пишем компонент фильтра, AJAX-обработчики, агенты синхронизации.
- Тестирование — нагрузочное тестирование на 1000+ товаров и 100+ городов, проверка на скорость.
- Деплой и документация — выкатываем на боевой сервер, передаём инструкцию по настройке и поддержке.
В документации 1С-Битрикс отмечено, что правильное кэширование увеличивает производительность в несколько раз.
Что входит в работу
- Разработка компонента фильтрации с автодополнением.
- Настройка тегированного кэширования.
- Интеграция с 1С (синхронизация справочника городов).
- Тестирование на пиковых нагрузках.
- Документация и обучение менеджеров.
- Гарантия на код.
Типичные ошибки при разработке геофильтра
- Неправильная индексация — забывают добавить индекс на PROPERTY_CITY, фильтр тормозит на 10 000+ элементах.
- Отсутствие кэширования — каждый запрос к фильтру делает 50+ SQL-запросов.
- Игнорирование мобильной версии — на телефоне список городов не влезает в экран, нужно автодополнение.
Мы работаем с Битриксом более 5 лет и выполнили 50+ проектов по геофильтрации.
Сроки и стоимость
Срок разработки — от 2 до 14 рабочих дней в зависимости от сложности. Стоимость рассчитывается индивидуально после аудита проекта, однако правильно спроектированное решение окупается за счёт экономии на поддержке и доработках. Экономия времени пользователей на поиск товаров может составлять до 50%, что напрямую влияет на конверсию и выручку. На все работы предоставляется гарантия 12 месяцев. Свяжитесь с нами для аудита и получите консультацию. Закажите разработку геофильтрации и ускорьте работу интернет-магазина.
Подробнее о типах местоположений в Битриксе или на Wikipedia о GeoIP.