Сайт на 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']) . '">'; -
Кошик та лічильники. Резервуємо місце через CSS:
min-width: 40px; min-height: 40px. -
Шрифти. Використовуємо
font-display: swap.
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С-Бітрікс.