Оптимізація LCP (Largest Contentful Paint) для 1С-Bitrix
LCP — час до відображення найбільшого видимого елемента на сторінці. Google вважає хорошим LCP < 2,5 секунди. Bitrix-сайти зазвичай показують 4–10 секунд, що прямо впливає на поісковое ранжування та конверсію.
Що є LCP-елементом
Браузер визначає LCP-елемент автоматично — це найбільший по площі контент у viewport при першому завантаженню. У Bitrix-магазині це звичайно:
- Головний банер/слайдер на головній сторінці
- Перше зображення товару на сторінці категорії
- Hero-зображення на лендінгу
Перевіртьте: Chrome DevTools → Performance → записати trace → в розділі Timings знайти LCP-маркер, кликнути — DevTools покаже конкретний елемент.
Чому LCP поганий: ланцюжок залежностей
Типова ланцюжок для банера у Bitrix-слайдері:
- Браузер запитує HTML → чекає TTFB (500 мс — 2 с)
- HTML розбирається → виявляється
<script src="swiper.min.js">у<head>— блокування - Завантажується Swiper.js (200 КБ), розбирається, виконується
- JS ініціалізує слайдер, створює
<img>в DOM - Браузер виявляє зображення → починає завантаження
- Зображення завантажується (PNG/JPEG, 500 КБ — 2 МБ)
- LCP зафіксований
На поганому з'єднанні 3G це 8–12 секунд. Кожен крок можна прискорити.
Усунення TTFB як основи LCP
LCP не може бути менший за TTFB — поки сервер не відав HTML, браузер не почав роботу. Оптимізація TTFB через SQL-індекси, кеш компонентів та OPcache — перший крок. Див. матеріал про оптимізацію TTFB.
Мета: TTFB < 200 мс для кешованих сторінок.
Preload LCP-зображення
Найефективніше дія — сказати браузеру про LCP-зображення до розбору HTML-тіла:
<!-- Додайте у <head> ДО всіх скриптів та стилів -->
<link rel="preload" as="image"
href="/upload/resize_cache/iblock/banner_main.webp"
fetchpriority="high"
imagesrcset="/upload/resize_cache/iblock/banner_main_800.webp 800w,
/upload/resize_cache/iblock/banner_main_1600.webp 1600w"
imagesizes="100vw">
У Bitrix додається через AddHeadString() на початку шаблона або прямо у header.php:
// У component_epilog.php або header.php
if ($arResult['BANNER_IMAGE']) {
$GLOBALS['APPLICATION']->AddHeadString(
'<link rel="preload" as="image" href="' . $arResult['BANNER_IMAGE'] . '" fetchpriority="high">',
true // true = додати на початок head
);
}
fetchpriority="high" вказує браузеру завантажувати цей ресурс з найвищим пріоритетом, випереджаючи інші зображення.
Статичний перший слайд замість JS-ініціалізації
Головний банер у Bitrix часто реалізований як JS-слайдер. Проблема: JS ініціалізує слайдер після завантаження та виконання скрипту — зображення з'являється з затримкою.
Рішення: перший слайд рендерити у статичному HTML, JS-слайдер ініціалізувати для подальшої взаємодії:
// У template.php компонента головного банера
$firstSlide = $arResult['ITEMS'][0];
?>
<!-- Статичний перший слайд — браузер бачить відразу -->
<div class="banner-slider" id="main-banner">
<div class="swiper-slide swiper-slide-active">
<img src="<?= $firstSlide['IMG']['SRC'] ?>"
width="<?= $firstSlide['IMG']['WIDTH'] ?>"
height="<?= $firstSlide['IMG']['HEIGHT'] ?>"
fetchpriority="high"
alt="<?= htmlspecialchars($firstSlide['NAME']) ?>">
</div>
</div>
<!-- JS ініціалізується після завантаження сторінки -->
<script defer>
document.addEventListener('DOMContentLoaded', function() {
new Swiper('#main-banner', { /* ... */ });
});
</script>
Оптимізація зображень
Формат. WebP дає 25–35% менший розмір порівняно з JPEG при тому ж візуальному якості. AVIF — ще 20–30% менше, але підтримка браузерами трохи гірша.
Bitrix вміє раздавати WebP через \Bitrix\Main\File\Image::resize() при ввімкненні у .settings.php. Для підтримки AVIF потрібен ImageMagick з AVIF-підтримкою або зовнішній сервіс.
Розмір. Зображення 3000×2000 px для банера на екрані 1920px — потрійний перерозхід. Налаштуйте розміри через CIBlock::GetPreviewPicture() або \Bitrix\Main\File\Image::resize():
$resizedImage = \CFile::ResizeImageGet(
$originalFileId,
['width' => 1920, 'height' => 600],
BX_RESIZE_IMAGE_PROPORTIONAL_ALT,
false,
false,
false,
90 // якість
);
Стиснення. Додаткова оптимізація через mozjpeg або oxipng на рівні сервера: якість без втрат, 15–20% розміру. Налаштовується через nginx-модуль ngx_http_image_filter_module або зовнішній оптимізатор при завантаженню файлу через обробник подій OnFileSave.
Рекомендації щодо responsive зображень
Мобільний користувач з екраном 375px не повинен завантажувати банер 1920px. Використовуйте srcset:
<img src="/upload/banners/banner_1200.webp"
srcset="/upload/banners/banner_480.webp 480w,
/upload/banners/banner_800.webp 800w,
/upload/banners/banner_1200.webp 1200w,
/upload/banners/banner_1920.webp 1920w"
sizes="100vw"
width="1920" height="600"
fetchpriority="high"
alt="Головний банер">
У Bitrix шаблоні: заздалегідь нарізайте кілька розмірів через CFile::ResizeImageGet() та виводите у srcset.
Терміни оптимізації LCP
| Задача | Терміни | Поліпшення LCP |
|---|---|---|
| Preload головного зображення | 0,5 дня | −0,5–1 с |
| Статичний перший слайд без JS-залежності | 1–2 дня | −1–2 с |
| WebP конвертація + resize | 1 день | −0,5–1,5 с |
| Оптимізація TTFB | 3–10 днів | −1–3 с |
| Defer/async для некритичних скриптів | 1 день | −0,3–0,8 с |
| Responsive images + srcset | 1–2 дня | −0,5–1 с |
При комплексній роботі реалістична мета: LCP < 2,5 с для мобільних, < 1,5 с для десктопа на кешованих сторінках.