Налаштування панелі продуктивності Бітрікс: діагностика та оптимізація

Коли сайт на Бітрікс починає гальмувати — клієнти скаржаться, менеджери нервують, а в адмінці кожен клік чекаєш по 10 секунд?

Перший інструмент, який має освоїти кожен розробник — вбудована панель продуктивності. Ми за 8 років на ринку та 50+ проєктах по Бітрікс не раз переконувалися: її даних вистачає для 80% завдань діагностики без зовнішніх профайлерів. Нещодавно до нас звернувся інтернет-магазин з каталогом 50 000 товарів — сторінка каталогу вантажилася 12 секунд. Після налаштування панелі та оптимізації SQL час упав до 1.2 секунди, економія в 10 разів — що в перерахунку на хостинг зекономило клієнту 75 000 грн щомісяця. Такі результати типові, коли знаєш, на що дивитися. Нижче розберемо, як налаштувати панель, інтерпретувати її показники та провести реальну оптимізацію.

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

Активується через адміністративний інтерфейс: Налаштування → Продуктивність → Панель продуктивності. Для швидкого налагодження можна ввімкнути програмно:

// Показувати панель для поточного користувача
$USER->SetShowStatPanel(true);

// Або в dbconn.php для налагодження на dev-оточенні
define('BX_STATPANEL', true);

Панель видно лише авторизованим користувачам у групі «Адміністратори». На production її варто тримати ввімкненою лише при активному налагодженні — вона сама додає невелике навантаження на збір даних. Згідно з офіційною документацією Бітрікс, панель не впливає на швидкість сторінки для звичайних відвідувачів.

Показники панелі продуктивності

• Час виконання — повний час PHP + SQL у мілісекундах. Розбивка: PHP-час і час очікування MySQL.
• Запити до БД — кількість SQL-запитів та їх сумарний час. Клацніть на блок — відкриється список усіх запитів із часом виконання кожного.
• Кеш — кількість звернень до кешу: hits (влучень) і misses (промахів). Низький hit rate (< 80%) — сигнал, що кеш неефективно налаштований або занадто часто інвалідується.
• Файли — кількість підключених PHP-файлів. 500+ файлів без OPcache — це повільна ініціалізація.
• Пам'ять — пікове споживання пам'яті PHP-скриптом. 64 МБ+ — варто перевірити, чи немає витоків або надмірних завантажень даних.

Для зручності зведемо нормальні значення в таблицю:

Типові проблеми та їх рішення зібрані в таблиці нижче.

Детальне профілювання SQL

Клацніть на блок SQL у панелі — відкриється список усіх запитів. Сортуйте за часом. Запити > 50 мс — кандидати на оптимізацію через EXPLAIN. Запити, що повторюються 10+ разів з однаковим шаблоном — N+1 проблема. Зазвичай це властивості елементів інфоблоку, що запитуються поелементно. Порівняння: правильно побудований запит з одним JOIN працює в 10-20 разів швидше, ніж N окремих запитів.

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

У меню Налаштування → Продуктивність → Монітор продуктивності задайте:

• Поріг запису в лог — 1000 мс для production, 500 мс для staging
• Зберігати записів — 1000–5000 записів у таблиці b_perf_hit
• Записувати SQL — увімкніть, щоб бачити список запитів для повільних сторінок

Перегляд логу: Налаштування → Продуктивність → Перегляд логу. Сортуйте за сумарним часом SQL — там будуть найпроблемніші сторінки.

Алгоритм діагностики конкретної проблеми

1. Відкрити повільну сторінку з увімкненою панеллю.
2. Подивитися співвідношення PHP-час / SQL-час. Якщо SQL > 70% — оптимізуємо запити. Якщо PHP-час великий при невеликому SQL — проблема в коді компонентів.
3. Відкрити список SQL-запитів, відсортувати за часом.
4. Скопіювати повільний запит, запустити EXPLAIN у MySQL Workbench або phpMyAdmin. Часто допомагає додавання індексу — час запиту падає в 5-10 разів.
5. Додати відсутній індекс, оновити сторінку, переконатися в покращенні.

Типова ситуація: на одному з проєктів сторінка каталогу вантажилася 8 секунд. Панель показала 250 SQL-запитів. EXPLAIN виявив відсутність індексів по полю IBLOCK_SECTION_ID. Після додавання індексу сторінка стала вантажитися за 0.8 секунди — покращення в 10 разів.

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

Панель чудово виявляє повільні SQL-запити та проблеми кешування, але не показує вузькі місця в асинхронному коді або зовнішніх API-викликах. Для глибокої діагностики ми додатково використовуємо Xdebug-профілювання та моніторинг у бік REST-сервісів (наприклад, 1С або платіжних шлюзів). Панель — перший ешелон діагностики, але не останній.

Як часто потрібно проводити аудит продуктивності?

Рекомендуємо запускати монітор продуктивності постійно, а розгорнутий аудит проводити раз на квартал або після великих оновлень. Це дозволяє виявляти деградацію на ранніх стадіях. Наприклад, після додавання нового розділу каталогу або інтеграції з новим API варто перевірити, чи не збільшилася кількість SQL-запитів.

Склад повного аудиту продуктивності

Якщо довірити діагностику нам, ви отримуєте:

• Повний аудит поточної продуктивності з використанням панелі та додаткових інструментів.
• Оптимізацію SQL-запитів: аналіз EXPLAIN, додавання індексів, рефакторинг ORM-запитів.
• Налаштування кешування: тегований кеш, HTML-кеш, композитний режим.
• Конфігурацію монітора продуктивності для постійного збору метрик.
• Підсумковий звіт з рекомендаціями та планом дій.
• Гарантію на результат — зафіксуємо цільові показники часу завантаження.

Середня економія після нашого аудиту становить 50 000-100 000 грн на місяць на інфраструктурних витратах. Замовте попередню безкоштовну діагностику за панеллю продуктивності. Зв'яжіться з нами для консультації щодо оптимізації.

SELECT TABLE_NAME, COLUMN_NAME, INDEX_NAME, NON_UNIQUE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'your_database';

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 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.