Оптимизация TTFB (Time to First Byte) 1С-Битрикс
TTFB — время от отправки HTTP-запроса до получения первого байта ответа. Это чистое серверное время: DNS, TCP-соединение, SSL-хендшейк плюс время генерации страницы. Google PageSpeed считает хорошим TTFB < 200 мс. У стандартного Битрикс-сайта без оптимизации — 800 мс — 3 секунды.
Из чего складывается TTFB в Битрикс
Типичная разбивка на тяжёлом сайте:
| Этап | Время | Что влияет |
|---|---|---|
| DNS + TCP + SSL | 20–100 мс | Хостинг, CDN, геолокация |
| Инициализация PHP + Битрикс | 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 компилирует каждый файл при каждом запросе. Битрикс при полной загрузке include-ит 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 — Битрикс с типовым набором модулей имеет 5000–15000 PHP-файлов. Если лимит меньше — часть файлов не кешируется. Проверить: opcache_get_status()['opcache_statistics']['num_cached_scripts'].
Кеш страниц и компонентов
Самый эффективный способ снизить TTFB — не генерировать страницу вообще, а отдать кешированный HTML. Битрикс умеет кешировать на нескольких уровнях:
Кеш компонентов ($cache_time в .parameters.php). Стандартный компонент bitrix:catalog.section кешируется на час. При правильной настройке повторный запрос страницы — это 5–20 SQL-запросов вместо 100–300.
Managed cache / composit. Технология Composite Site в Битрикс делит страницу на кешируемые и динамические части. Кешируемая часть (главная колонка, меню, шапка) отдаётся сразу, динамическая (корзина, счётчик уведомлений) догружается AJAX. При правильной настройке TTFB основного HTML падает до 50–100 мс.
Включение Composite: Настройки → Производительность → Составной сайт. Компоненты помечаются как динамические через CBitrixComponent::setDynamicMode() или через bitrix:catalog.top.menu с параметром DYNAMIC = Y.
HTML-кеш nginx. Самый быстрый вариант — nginx отдаёт статический HTML без запуска PHP. Реализуется через nginx FastCGI cache или Varnish перед Битрикс. Требует правильной инвалидации при обновлении контента.
Оптимизация пролога и init.php
Каждый запрос Битрикс выполняет /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/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 мс |
Реалистичная цель для интернет-магазина на Битрикс при комплексной оптимизации: TTFB < 300 мс для кешированных страниц, < 800 мс для динамических (личный кабинет, оформление заказа).