Оптимізація Core Web Vitals для 1С-Bitrix
Core Web Vitals — три метрики Google: LCP (швидкість завантаження головного контенту), CLS (стабільність макету), FID/INP (відзивність на введення). З 2021 року вони входять у поісковое ранжування. Для Bitrix-сайтів типова картина: LCP 4–8 секунд замість порогового 2,5 с, CLS 0,2–0,5 замість 0,1, FID/INP вище 200 мс.
Діагностика
Почніть з Chrome DevTools → Lighthouse → Performance. Це синтетика, але добре показує вузькі місця. PageSpeed Insights (pagespeed.web.dev) дає дані по реальним користувачам із CrUX (Chrome User Experience Report) — це важливіше синтетики для оцінки реального впливу на пошук.
Для Bitrix-сайтів основні джерела проблем:
- LCP: повільний TTFB + великі зображення у головному банері
- CLS: зображення без
width/height, шрифти безfont-display, динамічні блоки (кошик, банери) - FID/INP: важкий JavaScript, блокуючі скрипти у
<head>
LCP: критичний шлях рендерингу
LCP-елемент у Bitrix-магазині — звичайно головний банер (слайдер) або перше зображення у каталозі. Проблема: зображення підгружається через JS після рендерингу сторінки.
Рішення — preload для LCP-зображення:
<link rel="preload" as="image" href="/upload/banners/main.webp"
imagesizes="100vw" fetchpriority="high">
Додайте до <head> шаблона. У Bitrix — у header.php головного шаблона або через AddHeadString() у компоненті.
Слайдери — головний ворог LCP. Бібліотеки типу Swiper.js завантажують JS (100–300 КБ), який затримує показ першого слайду. Оптимізація: перший слайд рендерити у статичному HTML, JS-ініціалізацію відкладати через defer або requestIdleCallback.
CLS: смищення макету
CLS ненульовий у Bitrix через:
Зображення без розмірів. Стандартні компоненти Bitrix часто виводять <img src="..." alt="..."> без 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']) . '">';
Кошик та лічильники. Блок «У кошику: N товарів» або піктограма кошика у шапці — завантажуються AJAX після рендерингу та змищують контент. Резервуйте місце через CSS: min-width, min-height для блоків з динамічними даними.
Google Fonts та сторонні шрифти. Без font-display: swap браузер ховає текст до завантаження шрифту (FOIT), потім перерисовує. Додайте у CSS:
@font-face {
font-family: 'CustomFont';
src: url('/fonts/custom.woff2') format('woff2');
font-display: swap;
}
JavaScript: блокування рендерингу та INP
Типова проблема Bitrix: у <head> шаблона підключаються 10–20 JS-файлів через CJSCore::Init(). Браузер зупиняє розбір HTML при кожному синхронному <script>.
Перехід на defer:
<!-- Було (блокує рендеринг): -->
<script src="/bitrix/js/main/core.js"></script>
<!-- Стало: -->
<script src="/bitrix/js/main/core.js" defer></script>
У Bitrix управління скриптами через \Bitrix\Main\Page\Asset. Переключите вивід JS у footer через Налаштування → Головний модуль → Продуктивність → Переносити скрипти в кінець сторінки.
INP (Interaction to Next Paint) — замінює FID з березня 2024. Вимірює затримку на всі взаємодії, не тільки на першу. Основні винуватці: важкі обробники подій, синхронні операції в click-хендлерах. Діагностика через DevTools → Performance → INP.
Зображення: WebP та lazy loading
Bitrix вміє конвертувати зображення у WebP через модуль resize_image. Налаштування у /bitrix/.settings.php:
'resize_image' => [
'value' => [
'webp' => true,
'webp_quality' => 80,
],
],
Після ввімкнення функція CFile::ResizeImageGet() повертає WebP-версію для браузерів, що підтримують. Для старих браузерів — автоматичний fallback на JPEG/PNG.
Lazy loading для зображень поза viewport:
<img src="..." loading="lazy" decoding="async" width="300" height="200">
LCP-зображення не повинно бути loading="lazy" — це затримає його завантаження. Решта зображень — можна й потрібно.
CSS: критичний шлях
Bitrix завантажує CSS через \Bitrix\Main\Page\Asset::addCss(). Весь CSS виводиться у <head>, блокуючи рендеринг. Для прискорення першого відображення:
- Виділіть критичний CSS (стилі для видимого viewport) та встройте у
<style>у<head> - Решту CSS завантажуйте асинхронно:
<link rel="preload" as="style" onload="this.rel='stylesheet'">
Інструменти для визначення критичного CSS: critical (npm), PurgeCSS для видалення невикористовуваних стилів.
Терміни оптимізації
| Задача | Терміни | Влияние |
|---|---|---|
| Діагностика: PageSpeed + DevTools аналіз | 1 день | — |
| Preload LCP-зображення, lazy loading решти | 1–2 дня | LCP −1–2 с |
| Додавання width/height до зображень | 1–3 дня | CLS → 0 |
| Перенос JS у defer/footer | 1–2 дня | FID/INP −50–200 мс |
| WebP конвертація + оптимізація зображень | 1–2 дня | LCP −0,5–1,5 с |
| Критичний CSS | 2–3 дня | LCP −0,5–1 с |
| Оптимізація TTFB (SQL, кеш) | 3–10 днів | LCP −1–4 с |
Повна оптимізація Core Web Vitals для Bitrix-магазину з нуля — 3–5 тижнів роботи. Перші результаті помітні через тиждень.