Типовий сценарій: клієнт запускає рекламну кампанію на головну сторінку інтернет-магазину на 1С-Бітрікс, а LCP на мобільних перевищує 6 секунд. Половина відвідувачів іде, не дочекавшись завантаження. Ми регулярно стикаємося з такими проєктами і за 5 робочих днів доводимо LCP до 2.1 секунди. За час роботи ми накопичили досвід досягнення цільових метрик на десятках проєктів — понад 50 успішних кейсів. Наприклад, на одному проєкті ми знизили LCP з 8.2 до 1.9 секунди за 5 днів за рахунок впровадження preload і статичного слайдера. Оптимізація LCP прямо впливає на конверсію: покращення LCP на 1 секунду збільшує її на 2-5%.
Як визначити LCP-елемент на сторінці?
Браузер визначає LCP-елемент автоматично — це найбільший за площею контент у viewport при першому завантаженні. У Бітрікс-магазині це зазвичай:
- Головний банер/слайдер на головній сторінці
- Перше зображення товару на сторінці категорії
- Hero-зображення на лендингу
Перевірити можна кількома інструментами:
- Chrome DevTools → Performance → запис trace → у Timings знайти LCP-маркер — DevTools підсвітить елемент.
- Lighthouse у режимі Desktop/Mobile — звіт покаже LCP та рекомендації.
- WebPageTest — детальний водоспад завантаження із зазначенням LCP.
Для точного аналізу використовуйте комбінацію: Lighthouse для швидкої оцінки, 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 секунд. Кожен крок можна прискорити. Найефективніше втручання — розірвати цей ланцюжок до кроку 5, повідомивши браузеру про зображення заздалегідь. Preload зображень у 2-3 рази ефективніший за просте стиснення JPEG для LCP.
Що таке TTFB і як він впливає на LCP?
LCP не може бути меншим за TTFB — поки сервер не віддав HTML, браузер не почав роботу. TTFB (Time to First Byte) — час від запиту до першого байта відповіді сервера. На Бітрікс-сайтах часто завищений через неоптимальні SQL-запити та відсутність кешування. Ми вирішуємо це через аналіз повільних запитів, додавання індексів та налаштування тегованого кешу компонентів. На одному проєкті ми знайшли повільний запит у модулі каталогу, який виконувався 2.3 секунди. Додали складовий індекс на поля TABLE, і запит став виконуватися за 0.04 секунди. Мета: TTFB < 200 мс для кешованих сторінок. Докладніше про метрику TTFB можна прочитати у статті Wikipedia: Time to first byte.
Preload LCP-зображення
Найефективніша дія — повідомити браузеру про LCP-зображення до парсингу HTML-тіла. Preload пришвидшує завантаження зображення на 0.5-1 секунду. Це в 2-3 рази ефективніше за просту оптимізацію зображень.
<!-- Додати у <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>
Цей підхід дає виграш у LCP від 1 до 2 секунд.
Оптимізація зображень
Формат. WebP дає 25–35% менший розмір порівняно з JPEG за тієї самої візуальної якості. AVIF — ще 20–30% менше, але підтримка браузерами трохи гірша. Порівняння форматів у таблиці:
| Формат | Розмір (відн.) | Якість | Підтримка браузерів |
|---|---|---|---|
| JPEG | 100% | Висока | Усі |
| WebP | 65–75% | Така ж | 95%+ |
| AVIF | 45–55% | Вища | 80%+ |
Бітрікс вміє роздавати 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. Докладніше про налаштування зображень у Бітрікс: https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=103&LESSON_ID=10506
Рекомендації щодо 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="Головний банер — оптимізація LCP для 1С-Бітрікс">
У Бітрікс шаблоні: заздалегідь нарізайте кілька розмірів через CFile::ResizeImageGet() і виводьте в srcset. Вже на цьому етапі ви отримаєте приріст LCP.
Що входить у роботу
Оптимізація LCP під ключ включає:
- Технічне завдання з аналізом поточного LCP та рекомендаціями
- Розробку та впровадження preload, статичного слайдера, WebP
- Налаштування responsive зображень та srcset
- Оптимізацію TTFB (індекси, кеш, OPcache)
- Звіт із замірами до/після (LCP, TTFB, FID)
- Консультацію щодо подальшої підтримки
Комплексна оптимізація LCP — інвестиція зі швидкою окупністю. Наприклад, покращення LCP на 2-3 секунди при конверсії 2% може дати суттєвий додатковий дохід. Точний бюджет обговорюється індивідуально після аудиту.
Терміни оптимізації 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 с для десктопа на кешованих сторінках.
Понад 5 років на ринку, понад 50 реалізованих проєктів з прискорення Бітрікс-сайтів. Гарантуємо вимірний результат — фіксуємо метрики до та після. Зв'яжіться з нами для безкоштовного аудиту LCP. Отримайте консультацію та дізнайтеся, як швидко можна покращити ваш LCP.
Докладніше про метрику LCP можна прочитати у статті Wikipedia: Largest Contentful Paint.