Прискорення сайту на 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%. Замовте аудит швидкості свого проєкту — ми оцінимо поточну продуктивність і запропонуємо план робіт. Зв'яжіться з нами, щоб отримати консультацію.

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