Диагностика медленных страниц на Битрикс

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

Разделяем время: сервер, база, фронтенд

Первый шаг диагностики — понять, на каком уровне теряется время. Полное время загрузки страницы (то, что показывает браузер) складывается из трёх слагаемых, и лечатся они по-разному:

• TTFB (Time To First Byte) — время генерации HTML на сервере. Сюда входят PHP, SQL, обращения к внешним сервисам. Это «зона Битрикса».
• Загрузка ресурсов — CSS, JS, изображения, шрифты. Это фронтенд: сжатие, объединение, lazyload, CDN.
• Рендеринг и скрипты в браузере — время до интерактивности, layout shift, тяжёлый JavaScript.

Открой вкладку Network в DevTools и посмотри на первый документ: если TTFB измеряется секундами — проблема на бэкенде, и внешние оптимизаторы вроде PageSpeed тут не помогут. Если TTFB в норме (до 200–400 мс), а страница всё равно «тормозит» — копай во фронтенд. Эта развилка экономит часы: нет смысла настраивать webp, если сервер отдаёт HTML за три секунды.

Панель отладки Битрикса

Главный встроенный инструмент — административная панель отладки. Включается в профиле пользователя (Настройки → Настройки продукта → Профиль) флажком «Показывать отладочную информацию», либо через параметр в URL, если разработчик оставил соответствующий код. После включения внизу страницы появляется строка с ключевыми метриками генерации.

Что она показывает и на что смотреть:

Если запросов к базе много, а страница листинговая — почти наверняка не работает кэш компонентов. Если время SQL велико при небольшом числе запросов — среди них есть один-два «тяжёлых» запроса, которые надо ловить отдельно.

Профилировщик и тайминги компонентов

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

Так вы точечно находите виновника: например, bitrix:catalog.section генерируется 1,2 секунды и делает 40 запросов — значит, его кэш выключен или сбрасывается на каждом хите. Смотрите на:

• Время выполнения компонента — сортируйте страницу в голове по самым «дорогим».
• Кэширование — включён ли кэш компонента (CACHE_TYPE = A), не стоит ли режим «Не кэшировать».
• Автообновление кэша и его время жизни — слишком короткий TTL кэша обесценивает его.

Для серверного профилирования более глубоких проблем подключают Xhprof или Blackfire — они строят дерево вызовов PHP и показывают, в какой функции реально уходит время. Битрикс поддерживает интеграцию с Xhprof через модуль bitrix.xhprof. Это тяжёлая артиллерия для случаев, когда стандартная отладка показала, что дело не в компоненте, а в кастомном коде.

Тяжёлые SQL-запросы

Когда отладка указала на базу, следующий шаг — найти конкретные запросы. Битрикс умеет логировать все SQL-запросы хита: в .settings.php в секции connections для основного соединения можно включить сбор статистики, после чего в $DB->arQueryDebug или через модуль отладки видны все запросы с их временем.

Что искать:

• Запросы без индексов — их видно по большому времени на небольшой таблице. Проверяйте через EXPLAIN в консоли MySQL.
• N+1 — когда в цикле по товарам на каждой итерации идёт отдельный запрос за свойствами или ценами. Лечится выборкой пачкой или кэшированием.
• Обращения к b_iblock_element_property и таблицам свойств инфоблоков — на больших каталогах это классическое узкое место.

Статистика производительности и монитор

Разовые замеры показывают моментальный срез, но для картины в целом используйте «Монитор производительности» (модуль perfmon) в разделе Настройки → Производительность. Он собирает статистику за период тестирования и выдаёт усреднённые метрики: скорость разработки, конфигурация сервера, скорость базы данных.

Особенно полезны два инструмента внутри модуля:

• Таблица хитов — показывает самые медленные страницы сайта по реальным заходам, с временем и числом запросов. Это отвечает на вопрос «какие страницы вообще чинить в первую очередь».
• Индексы — модуль анализирует запросы и предлагает недостающие индексы для таблиц, что напрямую ускоряет базу.

Итоговый балл производительности Битрикса (в «баллах BX») — грубый ориентир: он полезен для сравнения «до и после», но не заменяет анализа конкретных страниц. Гнаться за высоким баллом ради балла не стоит.

Проверяем, работает ли кэш и композит

Самая частая причина медленных страниц на Битрикс — кэш, который фактически не работает. Проверяется это просто: два раза подряд откройте одну страницу и сравните число запросов к БД в панели отладки. Если на втором заходе оно почти не упало — кэш не срабатывает.

Типичные причины «мёртвого» кэша:

• В коде компонента или в шаблоне используется $APPLICATION->SetTitle() или другие вызовы, которые ломают кэширование, вынося логику за пределы кэша.
• Тип кэша выставлен N («не кэшировать») в параметрах компонента.
• Хранилище кэша — файлы на медленном диске; на нагруженных проектах кэш переносят в Memcached или Redis через .settings.php (cache.type).
• Автокэш отключён глобально в Настройки → Автокэширование.

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

Фронтенд и внешние инструменты

Если TTFB в норме, переходим на клиентскую сторону. Здесь работают внешние измерители: Google PageSpeed Insights, Lighthouse (встроен в DevTools) и WebPageTest. Они дают метрики Core Web Vitals — LCP, CLS, INP — и конкретный список проблем.

На что чаще всего указывают на Битрикс-проектах:

• Множество отдельных CSS/JS-файлов — решается штатным объединением и сжатием в Настройки → Настройки продукта → Оптимизация CSS и JavaScript.
• Несжатые и не переведённые в webp изображения, отсутствие lazyload.
• Отсутствие CDN для статики.
• Блокирующий сторонний JavaScript — счётчики, чаты, пиксели.

Важно: PageSpeed измеряет уже отданный HTML. Если сервер генерирует страницу медленно, высокий балл PageSpeed вы не получите никакими фронтенд-приёмами — вернётесь к диагностике бэкенда.

Итог

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

Если каталог или корзина стабильно тормозят под нагрузкой, а собственных рук на глубокий разбор не хватает, мы в B2Bsite проводим полный аудит производительности и ускоряем сайт на Битрикс: находим узкие места в компонентах и запросах, настраиваем кэш, композит и Core Web Vitals, а при необходимости пересматриваем архитектуру каталога под рост.