Оптимизация каталога 100K-1M товаров на 1С-Битрикс

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

Почему большой каталог ведёт себя иначе

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

Индекс фасетов: почему он решает половину проблем

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

Партиционирование и highload-блоки

Второй пласт работ — структура хранения. Партиционирование делит тяжёлые таблицы на части по логичному ключу, и база при выборке обращается только к нужной партиции, а не сканирует всю таблицу. Это особенно важно для свойств, остатков, цен и истории заказов, которые на большом каталоге разрастаются быстрее всего. Highload-блоки выносят характеристики товаров из инфоблоков в отдельное хранилище с собственными индексами — это разгружает основные таблицы каталога и ускоряет и фильтрацию, и выборки списков. Когда структура данных приведена в порядок, многие запросы ускоряются в разы без всякого вмешательства в железо. Если же база при этом ещё и плохо настроена, мы отдельно занимаемся настройкой MySQL и PostgreSQL под Битрикс, чтобы движок базы использовал индексы и память максимально эффективно.

Кеш, пагинация и фронтенд

На уровне отдачи страниц задача — не собирать тяжёлую страницу каталога заново при каждом заходе. Мы настраиваем кеш разделов, списков и блоков так, чтобы готовая страница отдавалась за доли секунды, и делаем инвалидацию по тегам — при изменении товара обновляется только связанный кеш, а не весь каталог. Пагинацию на глубоких листингах переводим с перебора на курсорную выборку по ключу, чтобы дальние страницы открывались так же быстро, как первые. Отдельно занимаемся фронтендом каталога: тяжёлые списки товаров грузят браузер не меньше, чем база — сервер. Здесь помогает работа над фронтендом и Core Web Vitals, чтобы ускорение на стороне сервера дошло до реального пользователя и улучшило поведенческие и ранжирование.

Обмен с 1С на больших объёмах

Выгрузка из 1С — это место, где большой каталог особенно уязвим. Полный обмен на сотни тысяч позиций идёт часами и нагружает сайт так, что он подтормаживает или падает прямо во время обновления цен и остатков. Мы разбиваем обмен на пакеты, переводим его на дельту, чтобы грузились только изменившиеся товары, и выносим тяжёлую индексацию и пересчёт фасетов в фоновые задачи. В результате обмен перестаёт ронять сайт, ночные простои уходят, а актуальные данные появляются быстрее. Для каталога на миллион SKU предсказуемый и лёгкий обмен с учётной системой не менее важен, чем скорость самих страниц: устаревшие остатки и цены приводят к ошибочным заказам и потере доверия покупателей.

SEO-страницы фильтров и индексация

Большой каталог — это ещё и тысячи потенциальных посадочных страниц по комбинациям фильтров, на которые идёт поисковый трафик. Если эти страницы генерируются на лету, тяжёлый каталог отдаёт их медленно, краулер уходит по таймауту и значительная часть каталога просто не попадает в индекс. Мы предгенерируем SEO-страницы фильтров в статику и обновляем их по расписанию: робот обходит каталог без задержек, страницы отдаются мгновенно, а в индекс попадает кратно больше посадочных. Для крупного интернет-магазина это прямой рост органического трафика, потому что именно длинный хвост запросов по характеристикам товаров приводит целевых покупателей.

Когда хватит точечных работ, а когда нужна полная переработка

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

Как мы ведём работу без риска для продаж

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

Что вы получаете по итогу

Результат оптимизации большого каталога — это не абстрактные проценты, а конкретные изменения, которые видит и покупатель, и бизнес. Страницы разделов открываются за доли секунды даже на тысячах товаров. Умный фильтр срабатывает мгновенно и не держит базу. Глубокая пагинация работает без задержек. Обмен с 1С идёт быстро и не роняет сайт. SEO-страницы фильтров индексируются и приводят трафик. Нагрузка на базу в пик падает, и каталог спокойно держит распродажи без падений. А главное — каталог получает запас на рост: добавление новых сотен тысяч SKU не возвращает старые проблемы, потому что архитектура к этому готова.

Типичные ошибки, которые мы исправляем

На больших каталогах из проекта в проект повторяются одни и те же ошибки, и важно их знать, чтобы понимать, откуда берутся тормоза. Первая — фильтр без индекса фасетов: его просто не включили или забыли перестроить после изменения структуры свойств. Вторая — все характеристики свалены в обычные инфоблоки вместо highload-блоков, из-за чего основные таблицы раздуты и любая выборка по ним тяжёлая. Третья — отсутствие кеша на разделах и списках, когда тяжёлая страница собирается заново при каждом заходе. Четвёртая — пагинация через перебор, которая на глубоких страницах сканирует сотни тысяч строк впустую. Пятая — полный обмен с 1С вместо дельты, который роняет сайт при каждом обновлении. Шестая — SEO-страницы фильтров, генерируемые на лету, из-за чего краулер не успевает обойти каталог. По отдельности каждая ошибка кажется мелочью, но вместе они превращают каталог на миллион SKU в постоянный источник тормозов и потерянных заказов.

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

Как мы измеряем результат

Любое наше изменение сопровождается замером, потому что на больших каталогах легко обмануться: страница может казаться быстрой на тестовом запросе и тормозить под реальным трафиком и фильтрами. Мы фиксируем метрики до начала работ — время отдачи раздела, скорость отклика фильтра, время глубокой пагинации, нагрузку на базу в пик, длительность обмена с 1С — и сравниваем их после каждого этапа. Это позволяет видеть реальный эффект, ловить регрессии и приоритизировать дальнейшие работы по фактической отдаче. В финальном отчёте вы получаете прозрачную картину: что было, что стало и за счёт чего. Никаких абстрактных обещаний — только измеримые цифры по вашему конкретному каталогу и его реальной нагрузке.

С чего начать

Начните с аудита. Дайте нам доступ к каталогу или хотя бы опишите масштаб — число SKU, число свойств, как устроен фильтр и обмен с 1С, где именно тормозит. Мы снимем профиль, найдём узкие места и пришлём план работ с приоритетами: что даст самый быстрый эффект, что потребует переработки и какой результат реально получить. Аудит каталога бесплатный, и по его итогам вы получите честную картину состояния каталога и понятную дорожную карту ускорения. Обсудим ваш каталог — и сделаем так, чтобы миллион товаров открывался так же быстро, как тысяча.