Оптимизация LCP (Largest Contentful Paint) для 1С-Битрикс
LCP — время до отображения наибольшего видимого элемента страницы. Google считает хорошим LCP < 2.5 секунды. На Битрикс-сайтах типичные значения — 4–10 секунд, и это напрямую влияет на поисковое ранжирование и конверсию.
Что является LCP-элементом
Браузер определяет LCP-элемент автоматически — это самый большой по площади контент в viewport при первой загрузке. В Битрикс-магазине это обычно:
- Главный баннер/слайдер на главной странице
- Первое изображение товара на странице категории
- Hero-изображение на лендинге
Проверить: Chrome DevTools → Performance → снять trace → в разделе Timings найти LCP-маркер, кликнуть — DevTools покажет конкретный элемент.
Почему LCP плохой: цепочка зависимостей
Типичная цепочка для баннера в Битрикс-слайдере:
- Браузер запрашивает 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">
В Битрикс добавляется через 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-инициализации
Главный баннер в Битрикс часто реализован как 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% меньше, но поддержка браузерами чуть хуже.
Битрикс умеет раздавать 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="Главный баннер">
В Битрикс шаблоне: заранее нарезайте несколько размеров через 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 с для десктопа на кешированных страницах.