Профілювання продуктивності сайту 1С-Бітрікс

Замедлення сайту без очевидної причини — типовий запит: «сайт став повільнішим, хостинг не змінювався, код не чіпали». Перший рефлекс — додати ресурсів серверу або ввімкнути кеш. Це рідко допомагає без розуміння, де саме втрачається час. Ми знаємо, що профілювання — процес вимірювання, а не вгадування, і пропонуємо системний підхід до прискорення вашого Бітрікс-проєкту. У 80% випадків проблема криється в SQL-запитах або неефективному кешуванні. Один з наших клієнтів скоротив час генерації сторінок з 12 до 1 секунди після аналізу графа викликів.

Чому профілювання — перший крок до прискорення?

Продуктивність Бітрікс-проєкту деградує на кількох рівнях одночасно, і кожен вимагає свого інструментарію. Наш досвід показує: без вимірювання неможливо прийняти правильне рішення. Ось рівні, які ми перевіряємо:

Починаємо завжди з браузерного рівня — він показує симптом. Потім спускаємося до PHP, далі до СУБД. За 10+ років роботи ми розробили методику, яка дає результат у 90% проєктів.

Як працює вбудований дебаґер Бітрікс?

Найшвидший старт — увімкнути відладчик прямо в панелі керування:

// Вмикається в /bitrix/admin/settings.php → Продуктивність
// або програмно:
define('BX_DEBUG', true);
define('SHOW_SQLS', true); // показує всі SQL-запити

У нижній частині сторінки з'являється панель з: часом генерації сторінки, кількістю SQL-запитів та сумарним часом, кількістю підключених файлів, статистикою кешу (hit/miss).

На що дивитися: якщо SQL-запитів > 100 або сумарний SQL-час > 1 с — проблема в базі даних. Якщо запитів мало, але час генерації великий — проблема в PHP-коді (важкі обчислення, повільні зовнішні API).

XHProf: граф викликів PHP

Для детального профілювання PHP встановлюємо XHProf або його форк Tideways:

# Ubuntu/Debian
apt install php8.1-xhprof

# php.ini або 90-xhprof.ini
extension=xhprof.so
xhprof.output_dir=/var/tmp/xhprof

Запускаємо профілювання через local/php_interface/init.php:

if (isset($_GET['__profile']) && $_SERVER['REMOTE_ADDR'] === '127.0.0.1') {
    xhprof_enable(XHPROF_FLAGS_CPU | XHPROF_FLAGS_MEMORY);

    register_shutdown_function(function () {
        $data = xhprof_disable();
        $dir  = '/var/tmp/xhprof';
        $run  = uniqid();
        file_put_contents("$dir/$run.xhprof", serialize($data));
        // Посилання на звіт
        error_log("XHProf: /xhprof/index.php?run=$run&source=bitrix");
    });
}

Додаємо ?__profile=1 до URL (тільки з локальної IP). Результат — граф викликів з часом кожної функції. Шукаємо функції з високим inclusive time — це кандидати на оптимізацію.

Blackfire: промислове профілювання

Blackfire.io — комерційний профілювальник, працює без зміни коду та доступний для production. Як зазначено в офіційній документації Blackfire, він будує граф викликів з агрегацією по 10 запитам (усуває шум), показує гарячі шляхи та пропонує рекомендації. Особливо корисний для проєктів з Бітрікс D7 — добре видно ланцюжки викликів через \Bitrix\Main\ORM.

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

Іноді вузьке місце — конкретний компонент. Вимірюємо його час:

$start = microtime(true);

$APPLICATION->IncludeComponent('bitrix:catalog.section', '.default', [
    'IBLOCK_ID' => 5,
    'CACHE_TYPE' => 'A',
    'CACHE_TIME' => 3600,
    // ...
]);

$elapsed = round((microtime(true) - $start) * 1000, 2);
// Логуємо, якщо повільніше порогу
if ($elapsed > 200) {
    \Bitrix\Main\Diag\Debug::writeToFile(
        "catalog.section: {$elapsed}ms",
        'SLOW_COMPONENT',
        '/local/logs/performance.log'
    );
}

\Bitrix\Main\Diag\Debug::writeToFile() — штатний спосіб логувати в Бітрікс. Не використовує error_log і не засмічує системні логи.

Чому кеш не працює і як це перевірити?

Бітрікс використовує кілька рівнів кешу: файловий (/bitrix/cache/), memcached/Redis, HTML-кеш сторінок. Ефективність можна оцінити через статистику кешу. Якщо get_misses близько до get_hits — кеш майже не працює. Причини: занадто короткий TTL, часті скидання при оновленні даних, кеш по $_SERVER['REQUEST_URI'] без урахування кукі.

Як ми знаходимо вузькі місця: кейс з практики

Один з наших клієнтів — дистриб'ютор FMCG з B2B-порталом на Бітрікс «Бізнес». Каталог містив 85 000 позицій з персоналізованими цінами за групами контрагентів. Скарга: сторінка каталогу завантажувалася 8–12 с.

Діагностика через Бітрікс-дебаґер: 340 SQL-запитів, сумарний час 4,8 с. XHProf вказав на CPrice::GetBasePrice() з 340 викликами — ціна запитувалася для кожного елемента окремо замість batch-запиту.

Рішення: переписати вибірку цін через CCatalogProductPrice::GetList() з фільтром за масивом ID:

$priceResult = \Bitrix\Catalog\PriceTable::getList([
    'filter' => ['PRODUCT_ID' => $productIds, 'CATALOG_GROUP_ID' => $userGroupId],
    'select' => ['PRODUCT_ID', 'PRICE', 'CURRENCY'],
]);
$prices = [];
while ($price = $priceResult->fetch()) {
    $prices[$price['PRODUCT_ID']] = $price;
}

Результат: 340 запитів → 1 запит за цінами, час генерації: 9 с → 0,8 с. Плюс увімкнули HTML-кеш компонента з тегованим скиданням через CACHE_GROUPS. Економія часу — понад 90%.

Що входить у роботу з профілювання

Кожен проєкт ми ведемо за прозорою схемою. У послугу входить:

• Детальна діагностика всіх рівнів (браузер, PHP, БД, сервер)
• Звіт зі знайденими вузькими місцями та оцінкою впливу
• Оптимізація коду: виправлення SQL-запитів, налаштування кешу, доопрацювання компонентів
• Налаштування моніторингу (New Relic APM, Бітрікс Monitor)
• Документація за змінами та рекомендації щодо подальшого розвитку
• Навчання вашої команди: як підтримувати швидкість сайту

Як проводиться профілювання: покрокова інструкція

1. Збір даних: вмикаємо дебаґер, збираємо профілі XHProf/Blackfire для ключових сторінок.
2. Аналіз: виявляємо повільні запити, функції з високим inclusive time, неефективний кеш.
3. Оптимізація: виправляємо SQL, переписуємо компоненти, налаштовуємо кеш та моніторинг.
4. Перевірка: повторне профілювання для підтвердження покращень.
5. Документування: фіксуємо зміни та рекомендації.

Терміни

Ми гарантуємо, що після оптимізації ваш сайт працюватиме швидше мінімум на 50%. З нами працюють компанії, які цінують досвід і прозорість — у нас понад 50 успішних проєктів із прискорення Бітрікс.

Замовте аудит продуктивності вже сьогодні — отримайте консультацію інженера з 10-річним досвідом роботи з Бітрікс.

80% сайтів на Бітрікс гальмують через одну таблицю

b_iblock_element_property — EAV-структура. Кожен рядок зберігає одне значення однієї властивості одного елемента. Каталог у 50 000 товарів з 30 властивостями дає 1,5 млн рядків. Коли розумний фільтр робить JOIN цієї таблиці з b_iblock_element за п'ятьма властивостями, MySQL іде в full table scan на 3–5 секунд.

Наш досвід показує: без втручання в цю таблицю прискорення неможливе. Ми беремося за проекти, де швидкість завантаження впала до 8–10 секунд, і повертаємо TTFB < 200 мс за 1–2 тижні. Оптимізація швидкості сайту починається з аудиту slow-запитів і закінчується комплексною перебудовою інфраструктури під ключ. У нашому портфоліо — понад 200 успішних проєктів. Ми — команда сертифікованих фахівців з 10‑річним досвідом роботи в Бітрікс.

Серверна оптимізація

Nginx. Не просто «увімкнули gzip». Конкретно:

• gzip_comp_level 4-5 — вище безглуздо, CPU з'їдає більше, ніж економить трафік;
• brotli on з brotli_static on — для попередньо стиснутих файлів (Brotli стискає на 20–30% краще за gzip);
• HTTP/2 з http2_max_concurrent_streams 128;
• fastcgi_cache для PHP-відповідей — кешування на рівні Nginx, минаючи PHP-FPM;
• worker_processes auto, worker_connections під кількість одночасних з'єднань.

PHP-FPM. Вибір між pm = dynamic і pm = static — не академічний:

• Static: фіксована кількість воркерів, без overhead на форк — для виділених серверів з передбачуваним навантаженням.
• Dynamic: економить RAM при низькому трафіку. pm.max_children рахуємо як (доступна RAM − RAM для MySQL/Redis) / середня витрата на процес.
• OPcache: opcache.memory_consumption=256, opcache.max_accelerated_files=20000, opcache.validate_timestamps=0 на продакшені (перезавантаження PHP-FPM при деплої).

MySQL/MariaDB. Головне вузьке місце майже завжди:

• slow_query_log з порогом 0.5 сек — кожен запит розбираємо через EXPLAIN.
• innodb_buffer_pool_size = 70–80% доступної RAM на виділеному сервері.
• Складені індекси для фасетного пошуку: (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) на b_iblock_element_property.
• OPTIMIZE TABLE b_iblock_element_property після масових операцій.

Як налаштувати кешування на три рівні?

Керований кеш компонентів. TTL налаштовуємо для кожного компонента окремо. Каталог — 3600 сек, новинна стрічка — 300 сек, банери — 86400. Однаковий TTL всюди — гарантія або застарілих даних, або марного кешу.

Композитний кеш. Технологія bitrix:composite — Nginx віддає готовий HTML із файлу, PHP не запускається. Динамічні зони (кошик, авторизація) підвантажуються AJAX-запитом через CBitrixComponent::setFrameMode(true). TTFB < 50 мс. Але не всі компоненти сумісні: $APPLICATION->ShowPanel() і прямий вивід через echo ламають композит. Перевіряємо кожну сторінку через панель «Продуктивність → Композитний сайт».

Порівняння: композитний кеш швидший за керований у 10–20 разів за часом першого байта. Офіційна документація Бітрікс з композитного кешу — Bitrix Composite.

Memcached / Redis. Переносимо кеш із файлової системи:

• Сесії → Redis (session.save_handler = redis) — швидше за файли в 10–50×, плюс робота в кластері.
• Кеш компонентів → Memcached через .settings.php: 'cache' => ['type' => 'memcache'].
• Кеш ORM-запитів — однакові GetList() не навантажують MySQL на кожному хіті.

Чому стандартних налаштувань MySQL недостатньо?

Індекси. Складені для фасетного пошуку. Покриваючі — для частих вибірок MySQL відповідає з індексу, не звертаючись до даних. Часткові індекси (MariaDB) для фільтрації за ACTIVE = 'Y'. Аудит невикористовуваних індексів — кожен сповільнює INSERT/UPDATE.

Партиціонування. Для таблиць з мільйонами рядків: b_stat_session, b_search_content_stem, Highload-блоки з історією. Партиція за датою — запит «замовлення за місяць» не сканує дані за три роки.

Реальний кейс: каталог 200 000 товарів, 50 властивостей. Фільтр за 10 властивостями займав 12 секунд. Після створення складених індексів за (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE) та партиціонування b_iblock_element_property за IBLOCK_ID час виконання впав до 0,3 секунди. Навантаження на MySQL знизилося в 40 разів. Це дозволило скоротити витрати на сервер до 40% без втрати продуктивності.

Очищення. У будь-якій базі за рік-два накопичується: застарілий пошуковий індекс, прострочені записи в b_cache_tag, історія b_iblock_element_prop_s*, логи в b_event_log на гігабайти. Налаштовуємо регулярне очищення через агенти.

Партиціонування також вирішує проблему з паралельними запитами при обміні з 1С через CommerceML. Докладніше: MySQL Partitioning Documentation.

Після аудиту вашого проекту ми визначимо вузькі місця за 2 години та запропонуємо конкретний план прискорення. Замовте безкоштовний аудит швидкості — заповніть форму на сайті.

Фронтенд

Зображення — 60–80% ваги сторінки:

• WebP через CFile::ResizeImageGet() з BX_RESIZE_IMAGE_PROPORTIONAL + конвертація;
• srcset + sizes — не завантажуємо 3000px картинку в блок 400px;
• loading="lazy" для всього нижче першого екрану;
• AVIF — ще 20–30% економії порівняно з WebP.

CSS/JS:

• Вбудований модуль Бітрікс: об'єднання та мініфікація через «Налаштування → Оптимізація CSS/JS»;
• PurgeCSS / UnCSS — на типовому Бітрікс-проекті 60–70% CSS не використовуються;
• defer / async для некритичного JS;
• Critical CSS інлайном у <head> для миттєвого FCP.

Шрифти:

• <link rel="preload" as="font" crossorigin> для основного шрифту;
• font-display: swap — текст видно одразу;
• Subsetting через pyftsubset — вирізаємо кирилицю + латиницю, файл зменшується в 3–5 разів.

CDN

Cloudflare, BunnyCDN, AWS CloudFront або локальні (Selectel CDN, VK Cloud CDN).

• Статика (CSS, JS, зображення, шрифти) — через CDN.
• Правила кешування: Cache-Control: public, max-age=31536000, immutable для файлів з хешем.
• Оптимізація зображень на льоту (imgproxy, Cloudflare Polish) без навантаження на origin.

Навіщо потрібне навантажувальне тестування?

Не синтетичні бенчмарки, а реальні сценарії:

• k6 / wrk — імітація маршрутів: каталог → фільтрація → картка → кошик → оформлення.
• Метрики: RPS, час відповіді (p50, p95, p99), відсоток помилок.
• Xdebug (callgrind) або Blackfire — профілювання PHP, пошук вузьких місць.

Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.

Результати

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

1. Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
2. Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
3. Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
4. Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
5. Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
6. CDN — підключення, налаштування правил кешування.
7. Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
8. Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
9. Гарантія — підтримка протягом 1 місяця після здачі.

Моніторинг

Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.

• web-vitals API — Real User Monitoring від реальних відвідувачів.
• Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
• Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.