Налаштування lazy load зображень у 1С-Бітрікс

Сторінка каталогу з 48 картками — браузер завантажує всі 48 зображень одразу, хоча видно лише 12. Шість мегабайт трафіку витрачається даремно, а показник LCP летить за 4 секунди. Ми стикалися з цим у кожному другому проекті на Бітрікс, тому налаштування lazy load включаємо в базовий пакет оптимізації. Наш досвід показує: правильне відкладене завантаження скорочує трафік на 70–80% і покращує Time to Interactive вдвічі. Наприклад, для магазину будівельних матеріалів з каталогом 15 000 товарів вдалося знизити LCP з 3,8 до 1,9 с, а обсяг зображень при першому відкритті — з 6,2 до 1,1 МБ. Економія трафіку склала 82%, що при середньомісячній відвідуваності 50 000 сесій і середньому чеку 3 500 грн дало додатковий виторг близько 280 000 грн на місяць за рахунок зниження відмов на 15%.

Чому lazy load критичний для інтернет-магазинів?

Кожне зображення — це HTTP-запит, декодування та відмальовування. Навіть при HTTP/2 браузер обмежує кількість одночасних з'єднань. Коли всі картки вимагають завантаження, черга блокує критично важливі ресурси: шрифти, CSS, скрипти аналітики. Результат — порожній екран і високий Bounce Rate. Наші клієнти після впровадження lazy load фіксують зниження відмов на 15–20%.

Як додати lazy load в 1С-Бітрікс?

Ми використовуємо комбінацію нативного атрибута loading="lazy" та IntersectionObserver для зворотної сумісності. Розглянемо обидва підходи.

Нативний lazy load (рекомендований)

Підтримується всіма сучасними браузерами. Достатньо додати атрибут у шаблон компонента:

<img src="<?= $item['PREVIEW_PICTURE']['SRC'] ?>" loading="lazy" width="<?= $item['PREVIEW_PICTURE']['WIDTH'] ?>" height="<?= $item['PREVIEW_PICTURE']['HEIGHT'] ?>" alt="Товар каталогу – відкладене завантаження зображень"> 

Важливо: атрибути width і height обов'язкові — без них браузер не резервує місце, і виникає зміщення контенту (CLS). Для зображень першого екрану (перші 2–4 рядки сітки) lazy load вимикаємо — інакше вони завантажаться із затримкою та погіршать LCP.

JavaScript-реалізація для старих браузерів

Якщо потрібна підтримка застарілих браузерів або кастомний прелоадер, застосовуємо IntersectionObserver:

const lazyImages = document.querySelectorAll('img[data-src]'); const observer = new IntersectionObserver((entries) => { entries.forEach(entry => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; img.removeAttribute('data-src'); observer.unobserve(img); } }); }, { rootMargin: '200px' }); lazyImages.forEach(img => observer.observe(img)); 

rootMargin: '200px' — завантаження починається за 200 пікселів до появи у viewport. Це запобігає «мерехтінню» при швидкому прокручуванні.

Порівняння підходів до lazy load

Нативний lazy load у 2–3 рази швидший за JavaScript-реалізацію за часом запуску, тому ми віддаємо перевагу йому як основному.

Типові метрики до та після впровадження lazy load

Чек-лист для самостійного налаштування:

• Перевірте, що на всіх тегах вказані width та height (резервування місця).
• Вимкніть lazy load для зображень першого екрану (перші 2–4 рядки сітки).
• Для фонових CSS-зображень реалізуйте IntersectionObserver із додаванням класу.
• Перевірте завантаження на повільних мережах (3G) за допомогою Chrome DevTools.
• Заміряйте LCP та CLS до та після змін.

Кейс із нашої практики

Клієнт: інтернет-магазин будівельних матеріалів з каталогом на 15 000 товарів. Проблема: сторінка розділу з 60 товарами завантажувала 6,2 МБ зображень, LCP — 3,8 с.

Що зробили:

• Додали loading="lazy" на всі картки, крім першого рядка.
• Для карток за фолдом встановили rootMargin: 300px через IntersectionObserver (стратегія: завантажувати заздалегідь, оскільки товари часто порівнюють).
• Оптимізували зображення через стиснення зі збереженням якості (WebP з fallback).

Результат: обсяг завантажуваних зображень при першому відкритті знизився до 1,1 МБ (економія 82%), LCP скоротився до 1,9 с. При прокручуванні користувач не помічає затримки. Додатковий виторг за рахунок зниження відмов — близько 280 000 грн на місяць при середньому чеку 3 500 грн.

Процес роботи над проектом

1. Аудит шаблонів: перевіряємо всі компоненти catalog.section, catalog.element, news.list — виявляємо місця, де завантажуються зображення без lazy load.
2. Проектування: складаємо карту зображень — які мають завантажуватися одразу (перший екран), які відкладено. Визначаємо rootMargin для різних зон.
3. Реалізація: правимо template.php, додаємо JS-код для старих браузерів. Для фонових CSS-зображень використовуємо IntersectionObserver з класом-маркером.
4. Тестування: перевіряємо на реальних пристроях (мережевий ліміт 3G), заміряємо LCP, CLS, TBT за допомогою Lighthouse та Chrome DevTools. Важливо виключити зміщення контенту на мобільних.
5. Деплой та моніторинг: викочуємо на стенд, потім прод. Налаштовуємо алерти в WebPageTest при погіршенні LCP більш ніж на 10%.

Що входить у роботу

• Технічна документація: схеми інтеграції lazy load, опис змінених шаблонів та JS-скриптів.
• Доступи: повний доступ до коду проекту та інструкцій для ваших розробників.
• Навчання: короткий вебінар для команди з підтримки lazy load.
• Пост-підтримка: місяць гарантійної підтримки — виправляємо баги та підлаштовуємо під нові вимоги.

Строки та вартість

Строки налаштування: від 4 до 16 годин залежно від складності архітектури. Для комплексних проектів із SSR та кастомними слайдерами час збільшується. Вартість розраховується індивідуально — зв'яжіться з нами, ми оцінимо ваш проект. Пропонуємо як окрему послугу, так і в складі комплексної оптимізації продуктивності з кешуванням, CDN та стисненням.

Налаштування lazy load — один із найшвидших способів покращити користувацький досвід. Наші спеціалісти мають сертифікати 1С-Бітрікс та понад 7 років досвіду — гарантуємо результат. Замовте аудит продуктивності вашого каталогу, щоб отримати конкретні рекомендації. Отримайте консультацію по вашому проекту.

Додаткові матеріали:

• MDN Web Docs: Lazy loading
• Wikipedia: Відкладене завантаження зображень