Медленный каталог на 1С-Битрикс нельзя надёжно вылечить одной универсальной настройкой. Одинаковый симптом — раздел или карточка долго открывается — возникает из-за разных причин: тяжёлого запроса к базе, лишней логики компонента, переполненного кеша, медленного внешнего сервиса, фоновой индексации или нехватки ресурсов сервера. Поэтому разумная оптимизация начинается не с установки очередного модуля и не с безусловного включения композита, а с измерений.
Ниже — порядок диагностики, который помогает отделить причину от совпадения. Он применим и к небольшому магазину, который внезапно замедлился после доработки, и к каталогу с сотнями тысяч товарных позиций. На большом проекте особенно важно проверять не только среднее время ответа, но и конкретные сценарии: раздел без фильтра, умный фильтр, карточку, поиск, обновление цены и обход поискового робота.
Сначала зафиксируйте симптом
Фраза «каталог тормозит» слишком расплывчата для постановки задачи. До изменения кода полезно ответить на несколько вопросов:
- медленно всем пользователям или только авторизованным;
- проблема постоянная или появляется в часы обмена, индексации либо резервного копирования;
- долго отвечает сервер или страница уже получена, но медленно отображается в браузере;
- тормозят все разделы либо только категории с большим числом товаров и свойств;
- меняется ли результат после очистки кеша;
- проблема воспроизводится на первой загрузке, на повторной или в обоих случаях.
В браузере откройте Network в инструментах разработчика и сравните время ожидания HTML-документа с загрузкой изображений, скриптов и шрифтов. Если долго приходит сам документ, нужно исследовать PHP, базу, кеш и внешние обращения. Если HTML приходит быстро, а интерфейс остаётся заблокированным, причина вероятнее во фронтенде, изображениях или сторонних виджетах. Это разные задачи, и оптимизация SQL не исправит тяжёлый JavaScript.
Для честного сравнения составьте небольшой набор контрольных URL: главная категория, глубокий раздел, страница с активным фильтром, карточка товара, поиск. Проверяйте одинаковые URL в одинаковых условиях и записывайте дату, состояние кеша и серверное время. Один замер не является доказательством: на него может повлиять прогрев кеша или временная фоновая нагрузка.
Разделите пользовательскую и серверную часть
Полезный ориентир — TTFB, то есть время до первого байта ответа. Он не объясняет причину, но показывает, где продолжать поиск. Высокий TTFB чаще указывает на выполнение PHP, запросы к базе, сессию, внешнее API или очередь процессов. Большой разрыв между получением HTML и готовностью страницы к взаимодействию указывает на клиентскую часть.
Для внешней картины подходят Chrome DevTools, Lighthouse или WebPageTest. Они показывают водопад запросов, объём ресурсов, блокирующие файлы и визуальные этапы загрузки. Но эти инструменты не заменяют серверное профилирование: из браузера невозможно увидеть, какой компонент выполнил сотни однотипных SQL-запросов.
На стороне 1С-Битрикс стоит начать со встроенной проверки системы и монитора производительности. Они помогают заметить общие проблемы конфигурации, ошибки окружения и медленные страницы. Для точечного разбора разработчик может использовать панель отладки Битрикс, статистику SQL, PHP-профилировщик вроде Xdebug или Blackfire, slow query log MySQL и системные метрики CPU, памяти, диска и очереди PHP-FPM. Набор инструментов зависит от доступа и окружения, но принцип один: измерять каждый слой отдельно.
Что обычно обнаруживается в SQL
Большой каталог не обязан быть медленным сам по себе. Проблемы начинаются, когда объём данных умножается на неудачную схему выборки. Например, компонент получает больше полей, чем выводит; для каждого товара отдельно загружается связанное значение; сортировка идёт по полю без подходящего индекса; фильтр объединяет множество свойств сложным условием.
При профилировании важно смотреть не только на один самый долгий запрос. Сотни запросов по несколько миллисекунд могут занимать больше времени, чем одна заметная выборка. Полезно искать:
- повторяющиеся запросы внутри цикла вывода товаров;
- выборки без ограничения нужных полей и записей;
- сортировки и соединения, которые создают временные таблицы;
- обращения к свойствам и ценам по одному элементу вместо пакетной загрузки;
- фильтры, время которых резко растёт в отдельных разделах;
- блокировки во время импорта, пересчёта или массового обновления.
Добавлять индекс «на всякий случай» опасно. Индекс ускоряет определённые чтения, но занимает место и увеличивает стоимость записи. Сначала нужно получить фактический запрос, посмотреть план через EXPLAIN, оценить селективность полей и только затем менять структуру базы. Не менее важно проверить код: иногда пакетная выборка или устранение запроса из цикла дают больший эффект без изменения схемы.
Компоненты, шаблоны и скрытая работа
Время каталога складывается не только из стандартного catalog.section. В шаблоне могут дополнительно вычисляться наличие, цены, скидки, связанные товары, SEO-тексты, рекомендации и данные внешней системы. Если каждый блок независимо запрашивает одни и те же сущности, страница выполняет много скрытой работы.
Проверьте параметры компонентов, result_modifier.php, component_epilog.php, обработчики событий и код шаблона. Отдельного внимания требуют вызовы API и HTTP-запросы во время формирования страницы. Ответ сервиса доставки, CRM или рекомендаций может быть нестабилен; синхронный вызов делает нестабильной и страницу каталога. Такие данные обычно получают заранее, кешируют с понятным сроком или загружают асинхронно, если бизнес-сценарий это допускает.
Иногда причина находится вне каталога: стартовые обработчики выполняются на каждом хите, сессия блокирует параллельные запросы одного пользователя, журналирование пишет слишком много данных на медленный диск. Поэтому вывод «виноват компонент каталога» должен подтверждаться профилем конкретного запроса.
Кеш: не переключатель, а политика актуальности
Кеширование полезно только тогда, когда понятно, какие данные и как долго могут быть неактуальными. Меню и неизменяемый текст можно хранить дольше. Цена, остаток и доступность заказа часто требуют более аккуратной инвалидизации. Если бездумно увеличить время кеша, страница ускорится в тесте, но покупатель может увидеть устаревшие условия.
Проверяйте:
- включён ли кеш у компонентов и не отключает ли его пользовательский код;
- входят ли в ключ кеша параметры, реально меняющие результат;
- очищается ли кеш после импорта и изменения сущностей;
- нет ли слишком широкой очистки при каждом обновлении товара;
- где хранится кеш и не упирается ли хранилище в диск или память;
- совпадает ли политика кеширования для анонимного и авторизованного пользователя.
Композитный режим может ускорить отдачу публичных страниц, но не исправляет тяжёлую динамическую область и не заменяет оптимизацию запросов. Его нужно проверять на реальных сценариях авторизации, персональных цен, корзины и остатков.
Фоновые процессы и индексация
Каталог может работать нормально большую часть дня и резко замедляться во время импорта, переиндексации поиска, генерации карты сайта, пересчёта фасетного индекса или резервного копирования. Здесь среднесуточный мониторинг скрывает проблему. Нужен временной график: когда началась деградация, какие cron-задачи или агенты выполнялись, росли ли CPU, I/O, число соединений с базой.
Проверьте расписание cron и агентов, длительность задач и возможность развести тяжёлые операции по времени. Агент, который должен обрабатывать данные порциями, не должен незаметно превращаться в полный обход каталога на пользовательском хите. После изменения расписания важно убедиться, что данные продолжают обновляться вовремя.
Такой сценарий был существенной частью работы над каталогом Geometria: проект содержал 800 000 SKU, а диагностика включала SQL-запросы, компоненты, кеширование и поведение при индексации. По опубликованному кейсу ключевые страницы ускорились примерно в пять раз, но это результат конкретного набора изменений на конкретном проекте, а не обещание для любого каталога.
Безопасный порядок оптимизации
Рабочий процесс выглядит так:
- Зафиксировать контрольные сценарии и исходные показатели.
- Снять профиль медленных запросов без изменения настроек.
- Связать задержку с конкретным компонентом, запросом или процессом.
- Сформулировать гипотезу и ожидаемый эффект.
- Внести одно логически отделимое изменение на тестовом контуре.
- Повторить те же замеры, проверить цены, остатки, фильтры и оформление заказа.
- Подготовить резервную копию и план отката перед продакшеном.
- Наблюдать за метриками после публикации, включая часы фоновой нагрузки.
Начинать лучше с изменений, которые устраняют лишнюю работу: запросы в цикле, повторное получение данных, неоправданные внешние вызовы. Переезд на более мощный сервер может дать запас, но не устраняет алгоритмическую проблему. И наоборот, нельзя заранее считать инфраструктуру невиновной: медленный диск, нехватка памяти или неправильно настроенный пул PHP способны ограничить даже аккуратный код.
Что передать специалисту
Чтобы диагностика не начиналась с переписки «у нас иногда медленно», подготовьте контрольные URL, время возникновения проблемы, видео или HAR-файл, сведения о последних релизах и расписание обменов. Нужны доступы к тестовому контуру, логам приложения, базе и системным метрикам — в объёме, который позволяет безопасно исследовать проблему.
На странице оптимизации каталога описан формат работы с такими задачами. Если проект передаётся новому исполнителю, пригодится и чек-лист передачи Битрикс-проекта: без резервной копии, staging и плана отката даже правильную гипотезу рискованно проверять на рабочем сайте.
Вывод
Ускорение каталога — это последовательное сокращение доказанной лишней работы. Сначала отделяют серверную задержку от фронтенда, затем профилируют SQL, компоненты, кеш и фоновые процессы. После этого изменения проверяют на одинаковых сценариях и только затем переносят в продакшен. Такой подход не даёт красивого универсального рецепта, зато позволяет улучшать производительность без потери актуальности данных и без случайных поломок.