Замедлення сайту без очевидної причини — типовий запит: «сайт став повільнішим, хостинг не змінювався, код не чіпали». Перший рефлекс — додати ресурсів серверу або ввімкнути кеш. Це рідко допомагає без розуміння, де саме втрачається час. Ми знаємо, що профілювання — процес вимірювання, а не вгадування, і пропонуємо системний підхід до прискорення вашого Бітрікс-проєкту. У 80% випадків проблема криється в SQL-запитах або неефективному кешуванні. Один з наших клієнтів скоротив час генерації сторінок з 12 до 1 секунди після аналізу графа викликів.
Чому профілювання — перший крок до прискорення?
Продуктивність Бітрікс-проєкту деградує на кількох рівнях одночасно, і кожен вимагає свого інструментарію. Наш досвід показує: без вимірювання неможливо прийняти правильне рішення. Ось рівні, які ми перевіряємо:
| Рівень | Інструменти | Що вимірює |
|---|---|---|
| Браузер / мережа | Lighthouse, WebPageTest, Chrome DevTools | FCP, LCP, TBT, водоспад запитів |
| PHP-додаток | Бітрікс Performance, XHProf, Blackfire | Час виконання функцій, граф викликів |
| СУБД | MySQL slow query log, EXPLAIN, Percona PMM |
Повільні запити, плани виконання |
| Сервер | htop, iostat, perf, Netdata |
CPU, I/O, пам'ять, контекстні перемикання |
Починаємо завжди з браузерного рівня — він показує симптом. Потім спускаємося до 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)
- Документація за змінами та рекомендації щодо подальшого розвитку
- Навчання вашої команди: як підтримувати швидкість сайту
Докладніше про моніторинг
Разове профілювання не захищає від регресій. Налаштовуємо baseline: - New Relic APM або Datadog — агент PHP, метрики в реальному часі - Бітрікс Monitor (модуль `monitor`) — вбудований моніторинг, зберігає історію - Алерти на Telegram/Email при перевищенні порогів (час відповіді > 2 с, помилки 500 > N за хвилину)Як проводиться профілювання: покрокова інструкція
- Збір даних: вмикаємо дебаґер, збираємо профілі XHProf/Blackfire для ключових сторінок.
- Аналіз: виявляємо повільні запити, функції з високим inclusive time, неефективний кеш.
- Оптимізація: виправляємо SQL, переписуємо компоненти, налаштовуємо кеш та моніторинг.
- Перевірка: повторне профілювання для підтвердження покращень.
- Документування: фіксуємо зміни та рекомендації.
Терміни
| Масштаб | Склад | Термін |
|---|---|---|
| Аудит | Діагностика, звіт з пріоритетами | 2-3 дні |
| Оптимізація виявлених проблем | Залежить від складності вузьких місць | від 5 до 20 днів |
| Налаштування моніторингу | Інструменти + алерти + baseline | 2-4 дні |
Ми гарантуємо, що після оптимізації ваш сайт працюватиме швидше мінімум на 50%. З нами працюють компанії, які цінують досвід і прозорість — у нас понад 50 успішних проєктів із прискорення Бітрікс.
Замовте аудит продуктивності вже сьогодні — отримайте консультацію інженера з 10-річним досвідом роботи з Бітрікс.







