Проект
geometria.top — интернет-магазин на 1С-Битрикс с каталогом примерно на 800 000 SKU.
CMS: 1С-Битрикс. Масштаб: ~800 000 товарных позиций. Задача была не «сделать сайт красивее», а вернуть каталогу рабочее время ответа.
Проблема
Ключевые страницы каталога загружались около 8 секунд. Для посетителя это потерянные просмотры. Для поиска — риск, что робот получит медленный ответ вне кеша. Для команды — постоянные тикеты «сайт опять лёг», которые на самом деле были смешением трёх разных процессов.
На большом инфоблоке ломается не «индексация как идея», а совпадение обмена с 1С, фоновых пересчётов и живого трафика на одной базе. Среднее время страницы за сутки при этом может выглядеть приемлемым. Падает окно, в котором всё стартует сразу.
Диагностика
Сначала нужно было доказать, какие URL и какие процессы дают 8 секунд, а не трогать шаблон раздела наугад.
Контрольные сценарии были одинаковыми до и после:
- раздел каталога без фильтра;
- тот же раздел с одним-двумя свойствами в фильтре;
- карточка из головы выдачи и карточка «с хвоста»;
- внутренний поиск;
- URL, который реально обходит поисковый робот.
Снималось время ответа документа, а не «ощущение в браузере». Сравнивались спокойное окно и окно обмена / переиндексации.
Отдельно смотрелись SQL-запросы компонентов каталога, повторяющиеся выборки, кеш и агенты, которые после обмена помечают поиск и фасеты как неактуальные.
Причины
На Битрикс-проекте слово «индексация» обычно означает три разных процесса:
- Поисковый индекс модуля поиска. Полный проход читает элементы, свойства, цены, доступность.
- Фасетный индекс умного фильтра. Он считает, какие значения свойств ещё доступны в разделе.
- Обход сайта поисковым роботом. Ему нужны стабильные 200 и внятный TTFB, но нагрузка идёт на те же PHP-FPM и базу.
На 5–10 тысячах SKU полный пересчёт часто незаметен. На сотнях тысяч SKU полный проход по свойствам — уже минуты и часы. Если в то же окно попадает обмен остатков из 1С, бэкап и робот по длинному хвосту карточек, покупатель и бот делят одни и те же ресурсы.
Параллельно каталог тянул лишние выборки в компонентах: данные, которые можно подготовить заранее или закешировать, каждый раз читались из базы.
Что изменили
- Профилировал SQL и сценарии открытия ключевых разделов.
- Убрал тяжёлые обращения к базе там, где данные можно было подготовить заранее или кешировать.
- Перевёл кеширование в предсказуемый режим для страниц, которые чаще всего открывают люди и роботы.
- Не кешировал агрессивно цены, остатки и фильтры — их актуальность важнее «ещё 200 мс».
- Стабилизировал поведение каталога при переиндексации, чтобы фон не превращался в простой витрины.
Изменения вносились поэтапно. Так можно было отделить полезную оптимизацию от случайных колебаний нагрузки.
До и после
| Замер | Значение |
|---|---|
| Масштаб | ~800 000 SKU |
| До | ~8 секунд на ключевых страницах |
| После | ~1,6 секунды |
| Результат | ускорение примерно в 5 раз |
| Индексация | 0 критичных срывов после стабилизации |
Технологии: PHP, MySQL, 1С-Битрикс, D7, SQL-профилирование, кеширование компонентов.
Результат для бизнеса
Ключевые страницы каталога стали открываться примерно за 1,6 секунды вместо 8. Это меньше потерянных переходов из-за ожидания и спокойнее SEO-обход: робот реже упирается в тяжёлый ответ вне кеша.
Для ассортиментной команды каталог перестал быть отдельным источником аварий в окне обмена. Ускорение не потребовало смены CMS и не потребовало «переписать каталог с нуля».
Подробный разбор услуги: ускорение каталога 1С-Битрикс.