Прискорення сайту на 1С-Бітрікс: знижуємо TTFB до 200 мс

Прискорення сайту на 1С-Бітрікс: знижуємо TTFB до 200 мс

Інтернет-магазин на Бітрікс завантажував сторінку каталогу 5 секунд, Google PageSpeed показував TTFB 1.2 секунди. Клієнт втрачав 30% конверсії. Після комплексної оптимізації TTFB впав до 180 мс — конверсія зросла на 15%. Наша команда з 8-річним досвідом роботи з Бітрікс виконала понад 120 проєктів з прискорення. Сертифіковані спеціалісти гарантують результат.

TTFB — час від відправлення HTTP-запиту до отримання першого байта відповіді. Це чистий серверний час: DNS, TCP-з'єднання, SSL-хендшейк плюс час генерації сторінки. Google PageSpeed вважає хорошим TTFB менше 200 мс. У стандартного Бітрікс-сайту без оптимізації — 800 мс – 3 секунди.

Чому TTFB важливий для ранжування?

Google враховує TTFB у складі Core Web Vitals з 2020 року. Згідно з Wikipedia, TTFB безпосередньо впливає на метрику Largest Contentful Paint. Для інтернет-магазину кожна зайва мілісекунда — втрата клієнта. Ми спостерігали: на проєктах, де TTFB знизили з 800 до 200 мс, органічний трафік зріс на 20-25% за три місяці. Середня окупність інвестицій в оптимізацію TTFB — 2-3 місяці за рахунок зростання конверсії.

З чого складається TTFB в Бітрікс

Типова розбивка на важкому сайті:

На більшості проєктів 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() для кожного файлу на кожен запит — сотні системних викликів. 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 / composite. Технологія Composite Site ділить сторінку на кешовані та динамічні частини. Кешована частина (головна колонка, меню) віддається одразу, динамічна (кошик, лічильник сповіщень) довантажується AJAX. При правильному налаштуванні TTFB основного HTML падає до 50–100 мс. Увімкнення: Налаштування → Продуктивність → Складений сайт. Компоненти позначаються як динамічні через CBitrixComponent::setDynamicMode() або параметр DYNAMIC = Y.

HTML-кеш nginx. Найшвидший варіант — nginx віддає статичний HTML без запуску PHP. Реалізується через nginx FastCGI cache або Varnish перед Бітрікс. Вимагає правильної інвалідації при оновленні контенту.

Як швидко знизити TTFB без ризику?

Якщо потрібно терміново покращити Core Web Vitals, почніть із трьох кроків:

1. Увімкніть OPcache з параметрами з розділу вище. Зниження TTFB: 100–300 мс.
2. Увімкніть композитний кеш (Composite Site) — зниження TTFB: 300–800 мс.
3. Оптимізуйте важкі SQL-запити через slow query log. Зниження TTFB: 200–1500 мс.

Ці кроки не вимагають зміни бізнес-логіки і виконуються за 1–2 дні. Ми перевіряємо кожен етап на staging-оточенні.

Як виміряти TTFB самостійно?

Для зовнішнього вимірювання використовуйте curl: curl -o /dev/null -s -w "Time to first byte: %{time_starttransfer}s\n" https://yoursite.ru/. Робіть 3–5 вимірів: перший може бути з холодним кешем. Для внутрішнього профілювання увімкніть панель продуктивності Бітрікс (/bitrix/admin/perfmon_panel.php). Вона покаже загальний час виконання, час SQL-запитів, час компонентів і кількість файлових операцій.

База даних: підключення та запити

Час встановлення з'єднання з MySQL — 1–5 мс при локальному з'єднанні. При винесенні БД на окремий сервер — 5–20 мс на TCP-з'єднання. Persistent connections (MYSQL_PCONNECT) дозволяють перевикористовувати з'єднання між запитам в рамках PHP-FPM воркера.

У /bitrix/php_interface/dbconn.php увімкніть:

$DBPersistent = true; 

Persistent connections знижують накладні витрати, але збільшують кількість відкритих з'єднань на сервері MySQL. max_connections в my.cnf має бути більшим за кількість PHP-FPM воркерів, помножену на кількість віртуальних хостів.

Оптимізація прологу та init.php

Кожен запит Бітрікс виконує /bitrix/php_interface/init.php. Якщо в ньому підключаються важкі класи, робляться SQL-запити або сторонні бібліотеки — це додається до кожного запиту. Перевірте, чи немає include файлів, які потрібні лише в конкретних контролерах, ініціалізації сторонніх SDK (1С-інтеграція, платіжні системи) при кожному запиті, або SQL-запитів в обробниках подій OnPageStart. Lazy-loading через Loader::includeModule() — підключайте модулі лише там, де вони потрібні.

Економічний ефект від зниження TTFB

Зниження TTFB на 600 мс дозволило одному з клієнтів збільшити дохід на 15% за рахунок зростання конверсії та покращення поведінкових факторів. Середня окупність інвестицій в оптимізацію TTFB — 2-3 місяці. Інший проєкт з каталогом 50 000 товарів після оптимізації скоротив TTFB з 1.2 с до 180 мс, що призвело до збільшення конверсії на 12%. Замовте аудит швидкості свого проєкту — ми оцінимо поточну продуктивність і запропонуємо план робіт. Зв'яжіться з нами, щоб отримати консультацію.