Оптимізація рендерингу сторінок 1С-Бітрікс: діагностика та рішення

Оптимізація рендерингу сторінок 1С-Бітрікс — наша спеціалізація. Ми стикалися з ситуацією, коли PageSpeed Insights показує 38 балів при LCP 4.2 секунди. TTFB — 1.8 с, а в HTML вже відданий повний контент. Проблема не в мережі і не в клієнтському JS — сторінка повільно формується на сервері. Інструментарій Бітрікс для діагностики є, але ним рідко користуються правильно. Наш досвід показує: у 80% випадків вузьким місцем виявляється неоптимальне кешування або N+1 запити в шаблонах. Особливо часто страждають сторінки каталогу з сотнями товарів — там кількість SQL може перевалювати за 400. Без системного підходу виправлення одного вузького місця може не дати ефекту, якщо не налаштоване кешування на всіх рівнях. Оптимізація рендерингу сторінок 1С-Бітрікс потребує комплексного аудиту та послідовних дій.

Чому сторінка рендериться повільно?

Основні причини:

• Компоненти працюють в неузгодженому режимі кешування (CACHE_TYPE=N).
• Цикли в шаблонах породжують N+1 SQL-запити.
• Вимкнено теговане кешування.
• Не налаштований композитний режим.

Діагностика проблеми

Алгоритм діагностики за 4 кроки:

1. Увімкніть панель налагодження: константи SHOW_PAGE_EXEC_TIME та SHOW_SQL_STAT в dbconn.php.
2. Проаналізуйте кількість SQL-запитів та час виконання — норма до 100 запитів за 0.5 с.
3. Визначте компоненти без кешу або з CACHE_TYPE=N.
4. Перевірте наявність N+1 запитів у шаблонах (виклики GetByID в циклах).

Діагностика через стандартні інструменти Бітрікс

Вмикаємо панель налагодження:

$_GET["show_page_exec_time"] або константа: define('SHOW_PAGE_EXEC_TIME', true); define('SHOW_SQL_STAT', true); 

Панель у footer сторінки покаже:

• сумарний час виконання
• кількість SQL-запитів та їх сумарний час
• об'єм спожитої пам'яті

Типова картина проблемної сторінки: 400+ SQL-запитів, 1.5–2.5 с на SQL при 0.3 с на PHP. Компоненти працюють в неузгодженому режимі кешування. Документація 1С-Бітрікс рекомендує використовувати теговане кешування для прискорення сторінок.

N+1 запити: виявлення та усунення

Найчастіша причина 400+ запитів — цикл за результатами із запитом всередині. Ця проблема відома як N+1 query problem.

// Погано: запит на кожен елемент foreach ($arResult['ITEMS'] as &$item) { $item['SECTION'] = \CIBlockSection::GetByID($item['IBLOCK_SECTION_ID'])->GetNext(); } 

Виправлення — агрегований запит до циклу:

$sectionIds = array_unique(array_column($arResult['ITEMS'], 'IBLOCK_SECTION_ID'])); $sections = []; $res = \CIBlockSection::GetList([], ['ID' => $sectionIds], false, ['ID', 'NAME', 'CODE']); while ($s = $res->GetNext()) { $sections[$s['ID']] = $s; } foreach ($arResult['ITEMS'] as &$item) { $item['SECTION'] = $sections[$item['IBLOCK_SECTION_ID']] ?? null; } 

Інструменти профілювання

Бітрікс не має вбудованого профайлера на рівні компонентів. Найпростіший спосіб — встановити модуль Bitrix Performance Monitor з Marketplace. Альтернатива — використовувати xhprof/Tideways з кастомною обгорткою. Для швидкої оцінки можна додати в init.php обробник, що виводить 10 найповільніших компонентів, але це потребує акуратності.

Як налаштувати композитний режим?

Композитний режим — вбудований механізм Бітрікс для кешування сторінок цілком із заміною динамічних блоків (кошик, авторизація) через AJAX. Він дає TTFB 50–100 мс для авторизованих користувачів. Однак композит потребує адаптації шаблону — не можна ввімкнути кнопкою без доробки компонентів. Ми рекомендуємо його для проєктів з високими вимогами до швидкості завантаження.

Порівняння типів кешування

Причини повільної роботи компонентів

Компонент без кешу або з кешем NONE

$APPLICATION->IncludeComponent('bitrix:catalog', '.default', [ 'CACHE_TYPE' => 'N', // <- вбивця продуктивності ]); 

Міняємо на:

'CACHE_TYPE' => 'A', // автоматично за налаштуваннями сайту 'CACHE_TIME' => 3600, // секунди 

Для компонентів, що залежать від користувача (кошик, особистий кабінет), кеш на рівні компонента не працює — тут потрібен AJAX-підхід: віддаємо шаблон з кешу, довантажуємо персональні дані окремим запитом.

Вимкнене кешування в складеному компоненті

Складений компонент (наприклад, bitrix:catalog) керує кешуванням дочірніх. Якщо в налаштуваннях розділу виставлено "Не кешувати" — кеш вимикається для всього дерева, включаючи секції лістингу товарів. Перевіряємо в налаштуваннях сайту: Налаштування → Налаштування продукту → Кешування. Теговане кешування (Bitrix Cache Engine) працює в 3 рази швидше за звичайне файлове — використовуйте його.

Оптимізація шаблонів

Мініфікація PHP-шаблонів. Бітрікс збирає сторінку з десятків include. Кожен include — звернення до файлової системи. На HDD-серверах це 5–15 мс на файл. Рішення — OPcache з opcache.validate_timestamps=0 у продакшні (ручна інвалідація кешу після деплою).

Винесення важких блоків в AJAX. Віджети типу «схожі товари», «нещодавно переглянуті», «популярні в категорії» — кандидати на винесення в AJAX. Основна сторінка рендериться швидко, віджети підвантажуються паралельно.

Приклад результату

Інтернет-магазин будівельних матеріалів, 180 000 SKU. До оптимізації: TTFB 2.1 с, 380 SQL на сторінці категорії. Після: вимкнено CACHE_TYPE=N у трьох компонентах, усунено два N+1, увімкнено OPcache validate_timestamps=0. Результат: TTFB 420 мс (в 5 разів швидше), 38 SQL запитів, LCP 1.9 с. Зниження навантаження на сервер дозволило скоротити витрати на VPS на 2000 грн щомісяця.

Етапи оптимізації

Що входить в роботу

• Документація з оптимізації
• Доступ до сервера та рекомендації
• Навчання розробника
• Підтримка 30 днів після здачі

Ми маємо 5 років досвіду з платформою 1С-Бітрікс та реалізували понад 50 проєктів з оптимізації. Оцінимо ваш проект безкоштовно — напишіть нам. Замовте аудит під ключ за 1 день — ми знайдемо вузькі місця. Зв'яжіться з нами для діагностики.