Оптимізація TTFB (Time to First Byte) для 1С-Bitrix
TTFB — час від відправки HTTP-запиту до отримання першого байта відповіді. Це чисте серверне час: DNS, TCP-з'єднання, SSL-хендшейк плюс час генерації сторінки. Google PageSpeed вважає хорошим TTFB < 200 мс. У стандартного Bitrix-сайту без оптимізації — 800 мс — 3 секунди.
З чого складається TTFB у Bitrix
Типова розбивка на важкому сайті:
| Етап | Час | Що впливає |
|---|---|---|
| DNS + TCP + SSL | 20–100 мс | Хостинг, CDN, геолокація |
| Ініціалізація PHP + Bitrix | 50–150 мс | OPcache, autoload |
| Завантаження ядра, модулів, пролог | 30–100 мс | Кількість модулів, include у init.php |
| SQL-запити до БД | 100–2000 мс | Індекси, кеш, оптимізація запитів |
| Виконання компонентів | 50–500 мс | Кеш компонентів, складність шаблонів |
| PHP-буфер, обфускатор | 10–50 мс | Налаштування виводу |
На більшості проектів 60–80% TTFB — це SQL-запити. Починати потрібно з них.
OPcache — базова оптимізація PHP
PHP без OPcache компілює кожен файл при кожному запиті. Bitrix при повному завантаженню підключає 200–500 PHP-файлів. OPcache кешує скомпільований байткод:
[opcache]
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0 ; на продакшені — не перевіряти зміни файлів
opcache.revalidate_freq = 0
opcache.fast_shutdown = 1
opcache.enable_cli = 0
validate_timestamps = 0 — критично для швидкості. При цьому OPcache не бачить змін файлів без скидання. Після розгортання скидайте кеш: opcache_reset() або cachetool утилітою. Без цього налаштування OPcache робить stat() для кожного файлу на кожен запит — сотні syscall-ів.
max_accelerated_files = 20000 — Bitrix з типовим набором модулів має 5000–15000 PHP-файлів. Якщо лімітація менше — частина файлів не кешується. Перевіртьте: opcache_get_status()['opcache_statistics']['num_cached_scripts'].
Кеш сторінок та компонентів
Найефективніший спосіб знизити TTFB — не генерувати сторінку зовсім, а відповісти кешованим HTML. Bitrix вміє кешувати на кількох рівнях:
Кеш компонентів ($cache_time у .parameters.php). Стандартний компонент bitrix:catalog.section кешується на годину. При правильному налаштуванні повторний запит сторінки — це 5–20 SQL-запитів замість 100–300.
Managed cache / Composite. Технологія Composite Site в Bitrix ділить сторінку на кешовані та динамічні частини. Кешована частина (головна колонка, меню, шапка) відповідається відразу, динамічна (кошик, лічильник повідомлень) завантажується AJAX. При правильному налаштуванні TTFB основного HTML падає до 50–100 мс.
Ввімкнення Composite: Налаштування → Продуктивність → Складний сайт. Компоненти помічаються як динамічні через CBitrixComponent::setDynamicMode() або через bitrix:catalog.top.menu з параметром DYNAMIC = Y.
HTML-кеш nginx. Найшвидший варіант — nginx відповідає статичний HTML без запуску PHP. Реалізується через nginx FastCGI cache або Varnish перед Bitrix. Потребує правильної інвалідації при оновленні контенту.
Оптимізація пролога та init.php
Кожен запит Bitrix виконує /bitrix/php_interface/init.php. Якщо в ньому підключаються важкі класи, роблять SQL-запити або підключають сторонні бібліотеки — це додається до кожного запиту.
Перевіртьте /bitrix/php_interface/init.php:
- немає
includeфайлів, які потрібні тільки в конкретних контролерах - немає ініціалізації сторонніх SDK (1C-інтеграція, платіжні системи) при кожному запиті
- немає SQL-запитів у обробниках подій
OnPageStart
Lazy-loading через Loader::includeModule() — модулі підключаються тільки там, де вони потрібні. Не підключайте в init.php весь список модулів глобально.
База даних: підключення та запити
Час встановлення з'єднання з MySQL — 1–5 мс при локальному з'єднанні. При виносі БД на окремий сервер — 5–20 мс на TCP-з'єднання. Persistent connections (MYSQL_PCONNECT) дозволяють переиспользувати з'єднання між запитами в рамках PHP-FPM воркера.
У /bitrix/php_interface/dbconn.php:
$DBPersistent = true; // ввімкнути persistent connections
Persistent connections знижують накладні витрати, але збільшують кількість відкритих з'єднань на сервері MySQL. max_connections у my.cnf повинен бути більший за число PHP-FPM воркерів × число віртуальних хостів.
Вимірювання TTFB по етапам
Інструмент діагностики — панель продуктивності Bitrix (/bitrix/admin/perfmon_panel.php або через піктограму в нижньому правому куті). Ввімкніть профілювання та відкрийте сторінку. Панель покаже:
- загальний час виконання
- час SQL-запитів суммарно та по запитам
- час виконання компонентів
- кількість файлових операцій кешу
Для зовнішнього вимірювання — curl -o /dev/null -s -w "Time to first byte: %{time_starttransfer}s\n" https://yoursite.ru/. Робіть 3–5 вимірювань: перше може бути з холодним кешем.
Терміни оптимізації
| Задача | Терміни | Зменшення TTFB |
|---|---|---|
| Налаштування OPcache | 0,5 дня | 100–300 мс |
| Оптимізація SQL (індекси, кеш) | 3–5 днів | 200–1500 мс |
| Налаштування кешу компонентів | 1–2 дня | 100–500 мс |
| Ввімкнення Composite Site | 2–3 дня | 300–800 мс |
| Перехід на Redis-кеш | 1 день | 20–100 мс |
| Nginx FastCGI cache | 2–3 дня | 200–600 мс |
Реалістична мета для інтернет-магазину на Bitrix при комплексній оптимізації: TTFB < 300 мс для кешованих сторінок, < 800 мс для динамічних (особистий кабінет, оформлення замовлення).