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

Наша компанія займається розробкою, підтримкою та обслуговуванням рішень на Бітрікс та Бітрікс24 будь-якої складності. Від простих односторінкових сайтів до складних інтернет-магазинів, CRM систем з інтеграцією 1С та телефонії. Досвід розробників підтверджено сертифікатами від вендора.
Пропоновані послуги
Показано 1 з 1 послугУсі 1626 послуг
Оптимізація рендерингу сторінок 1С-Бітрікс
Середня
~1-2 тижні
Часті питання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.png
    Розробка сайту компанії B2B ADVANCE
    1262
  • image_bitrix-bitrix-24-1c_fixper_448_0.png
    Розробка веб-сайту для компанії ФІКСПЕР
    851
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Розробка на базі Бітрікс, Бітрікс24, 1С для компанії Development of an Online
    585
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Розробка на базі 1С Підприємство для компанії МИРСАНБЕЛ
    751
  • image_crm_dolbimby_434_0.webp
    Розробка сайту на CRM Бітрікс24 для компанії DOLBIMBY
    657
  • image_crm_technotorgcomplex_453_0.webp
    Розробка на базі Бітрікс24 для компанії ТЕХНОТОРГКОМПЛЕКС
    989

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

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

PageSpeed Insights показує 38 балів при LCP 4.2 секунди. TTFB — 1.8 с, а в HTML вже відданий повний контент. Проблема не в мережі і не в клієнтському JS — сторінка повільно формується на сервері. Інструментарій Бітрікс для діагностики є, але ним рідко користуються правильно.

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

Вмикаємо налагоджувальну панель: $_GET["show_page_exec_time"] або через константу в dbconn.php:

define('SHOW_PAGE_EXEC_TIME', true);
define('SHOW_SQL_STAT', true);

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

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

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

Профілювання компонентів

Бітрікс не має вбудованого профайлера на рівні компонентів. Використовуємо microtime() навколо викликів:

// local/php_interface/init.php
AddEventHandler('main', 'OnBeforeEpilog', function() {
    global $APPLICATION;
    if (defined('SHOW_PAGE_EXEC_TIME') && SHOW_PAGE_EXEC_TIME) {
        $timers = \Bitrix\Main\Diag\Helper::getTimers();
        arsort($timers);
        echo '<pre>Top components by time:';
        array_splice($timers, 10);
        print_r($timers);
        echo '</pre>';
    }
});

Альтернатива — Bitrix Performance Monitor (модуль з Marketplace) або xhprof/Tideways через обгортку.

Головні винуватці повільного рендерингу

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

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

Змінюємо на:

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

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

N+1 у шаблонах компонентів

Найчастіша причина 400+ запитів — цикл за результатами з запитом всередині:

// Погано: запит на кожен елемент
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:catalog) керує кешуванням дочірніх. Якщо в налаштуваннях розділу виставлено «Не кешувати» — кеш вимикається для всього дерева, включаючи секції лістингу товарів.

Перевіряємо в налаштуваннях сайту: Налаштування → Налаштування продукту → Кешування.

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

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

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

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

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

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

Склад робіт та терміни

Етап Зміст Термін
Аудит Профілювання топ-5 сторінок, виявлення вузьких місць 1–2 дні
Оптимізація кешу Налаштування кешування компонентів 1–2 дні
Усунення N+1 Рефакторинг шаблонів з агрегованими запитами 2–5 днів
Композит Налаштування та адаптація шаблону 2–4 дні