Сайт на 1С-Бітрікс завантажується 4–8 секунд? LCP >4 с, CLS >0.2, INP >200 мс — типова картина для магазинів на цій CMS. Google враховує Core Web Vitals при ранжуванні, а користувачі йдуть при затримці більше 3 секунд. Ми проводимо аудит та оптимізацію під ключ: від діагностики до фінального тестування з гарантією проходження PageSpeed Insights. Досвід — 5+ років, понад 50 проєктів. Нещодавно ми працювали з інтернет-магазином автозапчастин на Бітрікс: LCP становив 6.2 с, CLS 0.3, INP 250 мс. Після оптимізації — LCP 1.8 с, CLS 0.05, INP 120 мс. Конверсія зросла на 22%, відмови знизилися на 25%. Інвестиції в оптимізацію окупаються за 3–6 місяців за рахунок зростання конверсії та зниження відмов.
Чому Core Web Vitals критичні для сайту на Бітрікс?
Google використовує ці метрики для оцінки користувацького досвіду. Погані Core Web Vitals знижують конверсію на 20–40% та погіршують позиції. Для сайтів на Бітрікс основні джерела проблем:
- LCP: повільний TTFB + великі зображення в головному банері
- CLS: зображення без width/height, шрифти без font-display, динамічні блоки (кошик, банери)
- INP: важкий JavaScript, блокуючі скрипти в head
На практиці кожен другий магазин на Бітрікс не проходить оцінку Google. Ми вирішуємо ці проблеми з гарантією результату.
Згідно з рекомендаціями Google, LCP має бути менше 2.5 секунд, CLS — менше 0.1, INP — менше 200 мілісекунд.
Що входить в оптимізацію Core Web Vitals?
Діагностика
Використовуємо Chrome DevTools Lighthouse для синтетики та PageSpeed Insights для даних реальних користувачів (CrUX). Оцінюємо TTFB, розмір JS/CSS, зображення, налаштування кешу. Результат — детальний звіт із пріоритетами.
LCP: критичний шлях рендерингу
LCP-елемент у магазині на Бітрікс — зазвичай головний банер або перше зображення. Проблема: зображення підвантажується через JS після рендерингу. Рішення — preload з fetchpriority="high":
<link rel="preload" as="image" href="/upload/banners/main.webp"
imagesizes="100vw" fetchpriority="high">
Додається в <head> через AddHeadString() компонента. Слайдери — головний ворог: Swiper.js додає 100–300 КБ JS. Оптимізація: перший слайд у статичному HTML, JS-ініціалізація через defer або requestIdleCallback.
CLS: зміщення макету
CLS ненульовий у Бітрікс через:
-
Зображення без розмірів. Стандартні компоненти часто виводять
<img> без width/height. Додаємо розміри:
// В template.php компонента catalog.element
$width = $arItem['PREVIEW_PICTURE']['WIDTH'] ?? 300;
$height = $arItem['PREVIEW_PICTURE']['HEIGHT'] ?? 300;
echo '<img src="' . $arItem['PREVIEW_PICTURE']['SRC'] . '" '
. 'width="' . $width . '" height="' . $height . '" '
. 'loading="lazy" decoding="async" alt="' . htmlspecialchars($arItem['NAME']) . '">';
JavaScript: блокування рендерингу та INP
У Бітрікс в <head> часто підключаються 10–20 JS-файлів через CJSCore::Init(). Переводимо на defer:
<script src="/bitrix/js/main/core.js" defer></script>
У налаштуваннях модуля «Продуктивність» вмикаємо перенесення скриптів у кінець сторінки. INP діагностуємо через DevTools Performance.
Зображення: WebP та lazy loading
Налаштовуємо модуль resize_image у /bitrix/.settings.php:
'resize_image' => [
'value' => [
'webp' => true,
'webp_quality' => 80,
],
],
Lazy loading для зображень поза екраном: loading="lazy" decoding="async". LCP-зображення — без lazy. WebP стискає зображення на 30-50% краще за JPEG без втрати якості, що прискорює завантаження.
CSS: критичний шлях
Вбудовуємо критичний CSS у <style> в <head>, решту завантажуємо асинхронно через <link rel="preload" as="style" onload="this.rel='stylesheet'">. Використовуємо PurgeCSS для видалення невикористовуваних стилів.
Як оптимізувати LCP покроково?
- Визначте LCP-елемент через Chrome DevTools.
- Переконайтеся, що це зображення попередньо завантажене з
fetchpriority="high".
- Оптимізуйте зображення: WebP з якістю 80%, розмір не більше 200 КБ.
- Налаштуйте кешування TTFB: використовуйте теговане кешування Бітрікс.
- Перенесіть блокуючі скрипти в footer або використовуйте
defer.
Як теговане кешування впливає на TTFB?
Теговане кешування в Бітрікс дозволяє скидати кеш лише тих блоків, які змінилися, замість повного скидання. Це знижує TTFB до 50 мс проти 200-400 мс без кешу. Налаштування ведеться через файл /bitrix/.settings.php та компоненти з підтримкою кешування.
Типові помилки при оптимізації
- Забувають про TTFB: без налаштування сервера та кешу LCP не покращиться.
- Використовують
loading="lazy" на LCP-зображенні — це погіршує LCP.
- Не резервують місце під динамічні блоки (кошик, слайдери) — CLS залишається високим.
Приклад розрахунку економії
При середньому чеку 2 000 грн. та конверсії 3%, зниження відмов на 25% дає додатково 30 замовлень на місяць з 10 000 відвідувачів. Разом +60 000 грн. виручки щомісяця.
Що ви отримуєте після оптимізації?
| Метрика |
До |
Після |
Покращення |
| LCP |
4–8 с |
<2.5 с |
у 2–3 рази |
| CLS |
0.2–0.5 |
<0.1 |
у 2–5 разів |
| INP |
>200 мс |
<200 мс |
>30% |
Порівняння методів оптимізації зображень
| Метод |
Стиснення |
Якість |
Підтримка |
| WebP |
30-50% |
висока |
всі сучасні браузери |
| JPEG |
10-20% |
середня |
універсальна |
| PNG |
без втрат |
висока |
універсальна |
Чому обирають нас?
- 5+ років досвіду з Бітрікс
- 50+ виконаних проєктів
- Сертифіковані спеціалісти
- Гарантія проходження PageSpeed Insights
Замовте аудит і отримайте детальний звіт з рекомендаціями. Зв'яжіться з нами для консультації — оцінимо ваш сайт і запропонуємо план оптимізації Core Web Vitals.
Докладніше про метрики: офіційна сторінка Core Web Vitals. Додаткова інформація з налаштування кешу: документація 1С-Бітрікс.
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, пошук вузьких місць.
Результат тестування — об'єктивна картина, де реально гальмує. Після оптимізації проганяємо повторно — фіксуємо покращення.
Результати
| Метрика |
До |
Після |
| TTFB |
800–2000 мс |
50–200 мс |
| Повне завантаження |
4–8 сек |
1.5–2.5 сек |
| PageSpeed (мобільний) |
30–50 |
80–95 |
| Одночасні користувачі |
50–100 |
500–2000+ |
Що входить у роботу?
-
Аудит поточної продуктивності — аналіз slow-запитів, профілювання PHP, перевірка кешування, CDN, серверних налаштувань.
-
Налаштування серверної частини — Nginx, PHP-FPM, MySQL, Redis/Memcached, OPcache.
-
Оптимізація кешування — керований кеш, композитний сайт, налаштування TTL, теговане кешування.
-
Робота з БД — створення індексів, партиціонування, очищення, реорганізація EAV-таблиць.
-
Фронтенд — зображення (WebP/AVIF), CSS/JS (мініфікація, deferred), шрифти (preload, subsetting).
-
CDN — підключення, налаштування правил кешування.
-
Навантажувальне тестування — сценарії реальних користувачів, звіт за метриками.
-
Документація — опис усіх змін, рекомендації щодо подальшого обслуговування.
-
Гарантія — підтримка протягом 1 місяця після здачі.
Моніторинг
Без моніторингу через півроку все деградує. Новий модуль, неочищені логи, зміна в шаблоні — і швидкість повернулася до початкової.
-
web-vitals API — Real User Monitoring від реальних відвідувачів.
-
Synthetic monitoring — Pingdom, UptimeRobot, регулярні перевірки з різних локацій.
-
Алерти — TTFB > 500 мс або LCP > 3 сек → сповіщення.
Терміни та вартість
| Тип робіт |
Терміни |
| Базова оптимізація (кеш, зображення, мініфікація) |
2–3 дні |
| Оптимізація БД (індекси, slow queries, налаштування) |
3–5 днів |
| Серверна інфраструктура (Nginx, PHP-FPM, Redis) |
2–3 дні |
| Комплексна (сервер + БД + фронтенд + CDN) |
1–3 тижні |
| Навантажувальне тестування та профілювання |
2–3 дні |
| Кластерна архітектура (балансування, реплікація) |
1–2 тижні |
Вартість розраховується індивідуально після аудиту. Отримайте консультацію щодо вашого проекту — оцінимо поточний стан і запропонуємо план прискорення з конкретними термінами та бюджетом. Ми — команда з 10+ роками досвіду в Бітрікс, виконали понад 200 проектів з оптимізації швидкості сайту. Замовте безкоштовний аудит швидкості — зв'яжіться з нами просто зараз.
