Кейс: оптимизация каталога с 50 000 SKU

На каталоге в пару тысяч товаров всё летает, и о производительности никто не думает. Но бизнес растёт, ассортимент подбирается к десяткам тысяч SKU — и внезапно списки открываются с задержкой, фильтр «думает» по несколько секунд, а в пик сайт начинает спотыкаться. Проблемы, незаметные на маленьком каталоге, на большом складываются и превращаются в потерю конверсии.

Это обобщённый разбор подхода к оптимизации большого каталога на 1С-Битрикс — на масштабе порядка 50 000 SKU с торговыми предложениями. Без выдуманных цифр и названий: только логика диагностики и мер, которые устойчиво дают эффект. Такую работу мы ведём в рамках аудита и оптимизации 1С, потому что скорость витрины на большом каталоге неразрывно связана с обменом и структурой данных.

С чего начинается замедление

Большой каталог тормозит не по одной причине, а из-за суммы факторов, каждый из которых по отдельности терпим. Тяжёлые выборки товаров с десятками свойств и торговыми предложениями. Умный фильтр без нужных индексов. Слабое кэширование, из-за которого каждый заход собирает данные заново. Обмен с 1С, который грузит базу в рабочее время. По отдельности — мелочь; вместе на 50 000 SKU — ощутимые задержки.

Важно понимать: это не «Битрикс медленный», а накопленные неоптимальности, которые не проявлялись на малом объёме. Поэтому оптимизация — это не поиск одной волшебной настройки, а системная работа по нескольким направлениям, начинающаяся с честной диагностики.

Диагностика: сначала измерить

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

• Профилирование страниц. Списки, фильтры, карточки — где именно уходит время на сборку.
• Тяжёлые запросы. Какие запросы к базе самые долгие и как часто они выполняются.
• Работа кэша. Что кэшируется, что нет, как часто пересобирается.
• Влияние обмена. Совпадают ли просадки скорости с окнами обмена с 1С.

По результатам диагностики появляется приоритизированный список: где эффект от исправления максимален. Дальше меры применяют по убыванию отдачи, а не «всё сразу». Это отличает результативную оптимизацию от бессистемной возни с настройками.

Структура инфоблоков и торговых предложений

Чаще всего корень тормозов — не «внешние» факторы, а сама структура данных. На большом каталоге критично, как устроены свойства товаров и торговых предложений.

• Избыточные свойства. Десятки свойств, часть из которых не используется, но тянутся на каждой выборке.
• Неоптимальные типы. Свойства неподходящих типов, по которым тяжело фильтровать и сортировать.
• Тяжёлые торговые предложения. Много вариантов с избыточными данными, выбираемых на каждой карточке.
• Лишние выборки. Данные, которые собираются, но не показываются.

Приведение структуры к разумной модели свойств и аккуратная работа с торговыми предложениями нередко дают больший эффект, чем любые внешние ускорители. Работать с данными эффективно помогает D7 ORM: точные выборки только нужных полей вместо «взять всё» разгружают базу на каждой странице.

Индексы и тяжёлые запросы

Вторая по частоте причина тормозов — запросы к базе без нужных индексов. На 50 000 SKU запрос, который без индекса перебирает всю таблицу, превращается из миллисекунд в секунды, а под нагрузкой множится и кладёт базу.

Работа здесь прицельная: по списку тяжёлых запросов из диагностики добавляют индексы, переписывают неоптимальные выборки, убирают избыточные обращения к базе. Каждое исправление проверяют замером — стало ли действительно быстрее, а не «по ощущениям».

Умный фильтр и фасетный индекс

В большом каталоге умный фильтр (catalog.smart.filter) — главный инструмент навигации: покупатель отсекает тысячи товаров до десятков по характеристикам. И он же — частое узкое место, если настроен неоптимально.

Что делает фильтр быстрым на десятках тысяч позиций:

1. Индексируемые свойства. Свойства, по которым идёт фильтрация, должны быть проиндексированы.
2. Фасетный индекс. Построенный и регулярно переиндексируемый фасетный индекс делает фильтрацию быстрой без перебора базы.
3. Разумный набор фильтров. Не выводить в фильтр всё подряд — только значимые для выбора свойства.
4. Актуальность индекса. Переиндексация после изменения данных, чтобы фильтр не врал по наличию.

Кэширование и композитный сайт

Даже быстрые запросы не стоит выполнять на каждый заход. Кэширование — обязательный слой оптимизации большого каталога.

• Кэш компонентов. Списки, меню, блоки каталога кэшируются, а не собираются заново каждый раз.
• Тегированный кэш. Точечный сброс только затронутых данных при изменении, а не всего кэша разом.
• Композитный сайт. Статическая часть страницы отдаётся мгновенно, а динамика (цена клиента, наличие) догружается.

Тонкость — корректный сброс кэша при обмене с 1С: иначе клиент увидит устаревшие цены и остатки. Баланс между скоростью и актуальностью настраивается прицельно через тегированный кэш. Подробнее о композите и кэшировании — в наших материалах по инфраструктуре; связку скорости и Core Web Vitals мы разбираем на практике, а фундамент окружения — в статье про хостинг и BitrixVM.

Обмен с 1С вне пика

На большом каталоге обмен с 1С сам может стать причиной тормозов. Если тяжёлая выгрузка идёт в рабочее время и грузит базу, посетители получают задержки именно в момент обмена. Оптимизация обмена включает несколько шагов.

1. Вынос тяжёлого в непиковые часы. Полные выгрузки — на время низкого трафика.
2. Обновление только изменившегося. Не перезагружать весь каталог, а обновлять то, что поменялось.
3. Корректный сброс кэша. После обмена сбрасывать только затронутый кэш, а не всё.
4. Контроль нагрузки. Следить, чтобы обмен не конкурировал с посетителями за ресурсы базы.

Правильно настроенный обмен обновляет цены и остатки, не мешая посетителям. Безопасность и надёжность обмена — отдельная важная тема, которую мы разбираем в статье про безопасность REST и вебхуков, а системную настройку обмена закрывает услуга автоматизации на 1С.

Инфраструктура и настройка окружения

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

Поэтому оптимизация всегда включает ревизию окружения: хватает ли ресурсов, правильно ли настроены кэш и база, нет ли узких мест на уровне инфраструктуры. Иногда грамотная настройка окружения даёт заметный прирост при минимальных правках кода. Как устроить надёжную среду для Битрикса, мы подробно разбираем в материале про хостинг и инфраструктуру BitrixVM.

Порядок работ на проекте

Устойчивая последовательность оптимизации большого каталога выглядит так.

1. Диагностика. Профилируем страницы, находим тяжёлые запросы и узкие места.
2. Структура данных. Приводим свойства и торговые предложения к разумной модели.
3. Индексы и запросы. Добавляем индексы, переписываем неоптимальные выборки.
4. Фильтр. Настраиваем фасетный индекс и разумный набор фильтров.
5. Кэш и композит. Включаем многоуровневый кэш и композитный сайт с корректным сбросом.
6. Обмен. Выносим тяжёлые операции из пика, обновляем только изменившееся.
7. Проверка замерами. Каждую меру подтверждаем измерением до/после.

Чтобы изменения выкатывались безопасно на работающий магазин, помогает настроенный CI/CD-деплой: оптимизации выкладываются предсказуемо и откатываются при проблемах.

Типовые результаты подхода

Точные цифры зависят от исходного состояния, поэтому назовём устойчивые направления эффекта.

• Быстрые списки и карточки. Страницы, открывавшиеся с задержкой, начинают отдаваться быстро.
• Фильтр перестаёт быть узким местом. Фасетный индекс делает фильтрацию мгновенной.
• Стабильность под нагрузкой. Сайт держит пик без падений и просадок.
• Лучше Core Web Vitals. Улучшаются показатели скорости, важные для конверсии и SEO.

Побочно снижается нагрузка на сервер и риск падений в пиковые периоды. Качественный сдвиг в том, что каталог перестаёт быть «бутылочным горлышком» роста: бизнес может расширять ассортимент, не упираясь в скорость.

Частые ошибки оптимизации

• Оптимизация без диагностики. Ускоряют то, что кажется медленным, а не то, что реально тормозит.
• Игнорируют структуру данных. Пытаются ускорить поверх кривой модели свойств — эффект минимален.
• Нет фасетного индекса. Фильтр перебирает базу на каждый клик.
• Кэш без корректного сброса. Скорость есть, но клиент видит устаревшие цены и остатки.
• Обмен в пик. Тяжёлая выгрузка грузит базу в час максимального трафика.
• Не проверяют замерами. «Оптимизировали» без измерения до/после, эффект не доказан.

Чек-лист оптимизации

1. Диагностика проведена. Известны тяжёлые запросы и узкие места.
2. Структура в порядке. Свойства и торговые предложения приведены к разумной модели.
3. Индексы добавлены. Тяжёлые запросы и сортировки проиндексированы.
4. Фильтр настроен. Фасетный индекс построен и переиндексируется.
5. Кэш работает. Многоуровневый кэш и композит с корректным сбросом.
6. Обмен вне пика. Тяжёлые операции — в непиковые часы, обновляется только изменившееся.
7. Окружение проверено. Ресурсы и настройки базы, кэша и веб-сервера оптимальны.
8. Эффект измерен. Каждая мера подтверждена замером до/после.

Вывод

Оптимизация каталога на 50 000 SKU — это не поиск волшебной настройки, а системная работа по нескольким направлениям, начинающаяся с диагностики. Фундамент — структура инфоблоков и торговых предложений; поверх кривой структуры ускорять малоэффективно. Дальше идут индексы, фасетный индекс умного фильтра, многоуровневый кэш с корректным сбросом, композитный сайт и вынос обмена с 1С из пика.

Устойчивый результат подхода — быстрые списки, фильтры и карточки, стабильность под нагрузкой и лучшие показатели Core Web Vitals. Ключевое правило на всех этапах — измерять: чинить то, что реально тормозит, и подтверждать каждую меру замером. Тогда каталог перестаёт быть тормозом роста, а бизнес может расширять ассортимент, не упираясь в производительность.