Оптимізація швидкості 1С-Бітрікс: налаштування композитного кешу до 50 мс

Сайт на 1С-Бітрікс гальмує: TTFB 800 мс, сервер задихається під навантаженням, а бюджет на хостинг зростає? Композитний кеш вирішує цю проблему кардинально — перший запит до сторінки виконується повністю (PHP + БД), результат зберігається як статичний HTML у /bitrix/cache/html/, а наступні запити віддаються безпосередньо з файлу через nginx. PHP взагалі не запускається. У цій статті ми детально розглянемо налаштування композитного кешу на 1С-Бітрікс. Композитний кеш — це найефективніший спосіб прискорити завантаження сторінок без модернізації сервера. TTFB падає з 800 мс до 20–50 мс, навантаження на PHP-FPM знижується на 90% і більше. Динамічні блоки (кошик, ім'я користувача, залишки) замінюються AJAX-запитами після завантаження сторінки.

За 5 років роботи ми провели понад 50 успішних впроваджень композитного кешу на проектах різного масштабу — від інтернет-магазинів до новинних порталів з відвідуваністю 100 000+ унікалів на добу. Наша компанія має 5+ років досвіду та понад 50 впроваджень композитного кешу. Композитний кеш у 10-20 разів прискорює TTFB порівняно зі звичайним кешуванням без статичного HTML, а також у 5 разів швидше за звичайне кешування сторінок. Нижче розповімо, як це працює і які підводні камені потрібно врахувати.

Передумови та вимоги

Які вимоги до сервера та ліцензії?

Для роботи композиту необхідні:

• Ліцензія «Бізнес» або вище (у «Старт» та «Стандарт» функція недоступна)
• Модуль bitrix.composite (встановлюється з Маркетплейсу, у старих версіях вбудований)
• Правильна конфігурація nginx для віддачі HTML-кешу без PHP

Конфігурація nginx — критичний момент. Без неї композит працює «наполовину»: HTML зберігається, але PHP все одно викликається для перевірки кешу. Потрібно додати в блок server умову, яка перевіряє наявність файлу кешу і віддає його напряму:

set $composite_cache "";
if (!-f $document_root/bitrix/cache/html/$host$request_uri/index.html) {
    set $composite_cache "no";
}
if ($composite_cache = "") {
    rewrite ^ /bitrix/cache/html/$host$request_uri/index.html last;
}

Точна конфігурація залежить від версії Бітрікс та структури сайту — офіційна документація містить кілька варіантів для різних схем URL. Детальніше про кешування у вебі можна прочитати в Wikipedia, а офіційна документація Бітрікс по композитному режиму — на helpdesk.bitrix24.ru.

Правильна розмітка динамічних зон

Головна проблема з композитом — неправильна розмітка динамічних зон. Все, що не повинно потрапити в статичний кеш, обгортається тегом bitrix:nocache:

<?$APPLICATION->IncludeComponent("bitrix:sale.basket.basket", ".default",
    array("CACHE_TYPE" => "N"), false);?>

У сучасних проектах динамічні зони виносяться в окремі AJAX-ендпоінти і підвантажуються через BX.ajax після завантаження сторінки. Типові блоки, що потребують nocache: кошик і лічильник товарів, блок авторизації, віджети порівняння, персоналізовані рекомендації, залишки на складі якщо вони змінюються часто.

Обмеження для авторизованих користувачів

За замовчуванням композит віддає статичний HTML лише анонімним користувачам. Для авторизованих завжди виконується повний PHP-цикл, щоб коректно відображати персоналізований контент. Існує режим асинхронної персоналізації через bitrix:composite.async, але він потребує окремого опрацювання і акуратної розмітки. Сторінки з POST-параметрами та зі списку винятків (/personal/, /order/) також не кешуються.

Вплив композитного кешу на SEO

Google і Yandex використовують час завантаження сторінки як фактор ранжування. TTFB менше 200 мс вважається відмінним, а композит дає 20–50 мс. Крім того, статичний HTML швидше індексується, що покращує швидкість краулінгу. Для пошукових систем це сигнал якісного сайту. Важливо переконатися, що всі SEO-елементи (meta-теги, заголовки) коректно виведені в кешованому HTML — при правильній розмітці це не проблема.

Кейс із нашої практики

Наш клієнт — новинний портал з відвідуваністю 40 000 унікалів на добу, переважно анонімні користувачі. TTFB на статтях — 650–900 мс, сервер під навантаженням у пікові години. Після налаштування композиту для сторінок статей (динамічний лише блок «останні коментарі» через AJAX) TTFB впав до 15–30 мс. Навантаження на PHP-FPM знизилося настільки, що знадобилося зменшити кількість воркерів — вони простоювали. Економія на ресурсах склала понад 30 000 гривень на місяць за рахунок відмови від додаткових серверів. Вартість налаштування композитного кешу на такому проекті — від 5 000 грн, що окупається за 2-3 місяці. Зв'яжіться з нами для подібного аудиту вашого проекту.

Що входить у налаштування композитного кешу

1. Аудит усіх компонентів на сторінці: виявляємо динамічні зони, які потрібно розмітити.
2. Налаштування nginx: додаємо правила віддачі статичного кешу.
3. Розмітка nocache-зон: обгортаємо кошик, авторизацію, порівняння та інші блоки.
4. Переведення частини динамічних блоків на AJAX-підвантаження для ще більшого прискорення.
5. Тестування за різними сценаріями: анонімний, авторизований, мобільний.
6. Моніторинг: перевіряємо заголовки відповіді та TTFB через DevTools.

Порівняння до та після

Типові терміни налаштування композитного кешу

Які типові помилки виникають при налаштуванні композитного кешу?

Композит не працює для авторизованих користувачів за замовчуванням — для них завжди виконується повний PHP-цикл. Часта помилка — увімкнути композит глобально без розмітки nocache у потрібних місцях. Результат: дані одного користувача потрапляють у кеш і відображаються іншому. Це виявляється не одразу і створює серйозні проблеми з безпекою. Інша помилка — ігнорування тегованого кешування, що призводить до надмірного скидання кешу при найменших змінах.

Перевірка роботи композитного кешу

Відкрийте сторінку в режимі інкогніто і подивіться заголовки відповіді. Якщо в response є X-Bitrix-Composite: Cache або у вихідному коді сторінки присутній коментар <!-- Композитний режим: кеш -->, значить кеш активний. TTFB менше 50 мс — вірна ознака коректної роботи. Рекомендуємо також перевірити роботу з динамічними блоками: після завантаження сторінки кошик і авторизація повинні оновлюватися через AJAX.

Готові прискорити ваш сайт? Замовте аудит композитного кешу та отримайте консультацію. Ми гарантуємо прискорення в 10 разів. Зв'яжіться з нами для попередньої оцінки вашого проекту.

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