Ускорение загрузки изображений (lazyload, webp)

Изображения — самый тяжёлый ресурс типового магазина на 1С-Битрикс: карточки, листинги и баннеры дают до 60–70% веса страницы. Грамотный lazyload и перевод графики в WebP снимают эту нагрузку без ущерба для качества и вёрстки. Разберём, что и как настраивать именно в Битрикс.

Почему изображения тормозят каталог

Браузер начинает грузить все <img> в разметке сразу, даже те, что находятся глубоко за пределами экрана. На странице листинга с 40 товарами это десятки запросов и мегабайты трафика ещё до того, как пользователь докрутил до первой карточки. Результат — медленный LCP (Largest Contentful Paint) и просадка в Core Web Vitals.

Вторая проблема — оригиналы. Часто в каталог заливают фото прямо из 1С или от поставщика: JPEG 2500×2500 весом 1–3 МБ, который потом отображается в блоке 300×300. Браузер всё равно скачивает полный файл. Здесь работают три рычага:

• Ресайз — отдавать картинку под реальный размер блока, а не оригинал;
• Формат — WebP вместо JPEG/PNG экономит 25–35% веса при том же визуальном качестве;
• Lazyload — грузить только то, что попадает или вот-вот попадёт в область видимости.

Ресайз средствами Битрикс

В Битрикс за уменьшение отвечает функция CFile::ResizeImageGet(). Она создаёт кэшированную копию нужного размера в /upload/resize_cache/ и возвращает путь к ней. Никогда не выводите в вёрстку DETAIL_PICTURE['SRC'] напрямую — это и есть тот самый оригинал.

Типовые компоненты bitrix:catalog и bitrix:news умеют ресайзить сами: в настройках компонента задаются параметры DETAIL_PICTURE_WIDTH/HEIGHT и LIST_PICTURE_WIDTH/HEIGHT. Убедитесь, что они заполнены и совпадают с реальными размерами блоков в дизайне.

В кастомном шаблоне вызов выглядит так:

• $file = CFile::ResizeImageGet($id, ['width'=>300,'height'=>300], BX_RESIZE_IMAGE_PROPORTIONAL, true);
• BX_RESIZE_IMAGE_PROPORTIONAL — вписать с сохранением пропорций;
• BX_RESIZE_IMAGE_EXACT — обрезать точно под размер (удобно для квадратных превью).

Перевод графики в WebP

WebP — формат от Google, который поддерживают все актуальные браузеры. Он даёт заметную экономию веса и умеет как lossless, так и прозрачность (замена PNG). В Битрикс есть несколько путей внедрения.

Ключевое требование — graceful fallback: старым клиентам и поисковым краулерам, которые не прислали image/webp в заголовке Accept, отдаём исходный JPEG/PNG. В разметке это решается тегом <picture>:

• <picture><source srcset="foto.webp" type="image/webp"><img src="foto.jpg" alt="…"></picture>

Так браузер сам выберет WebP, если умеет, и не сломается, если нет.

Настройка отложенной загрузки

Самый надёжный способ — нативный loading="lazy". Он не требует JavaScript и поддерживается всеми современными браузерами: браузер сам откладывает загрузку картинок вне вьюпорта.

1. Добавьте атрибут ко всем товарным изображениям в шаблонах листинга и карточки: <img src="…" loading="lazy" alt="…">;
2. Обязательно проставьте атрибуты width и height — они резервируют место и убирают сдвиг вёрстки (метрика CLS);
3. Для сложных сценариев (фоновые картинки, слайдеры) используйте JS-библиотеку с IntersectionObserver и подменой data-src → src.

Если на сайте включён композит, помните: HTML первого экрана отдаётся из кэша, поэтому проверяйте, что атрибуты попали именно в композитную версию страницы, а не только в динамическую.

Адаптивные картинки: srcset и sizes

Один и тот же файл не должен грузиться и на десктоп, и на телефон. Атрибуты srcset и sizes позволяют браузеру выбрать подходящий вариант под ширину экрана и плотность пикселей.

• srcset — список версий с указанием ширины: foto-300.jpg 300w, foto-600.jpg 600w, foto-900.jpg 900w;
• sizes — подсказка, какую ширину займёт картинка в макете: (max-width: 768px) 50vw, 300px.

Генерировать эти версии удобно тем же CFile::ResizeImageGet() в цикле по нужным размерам — прямо в шаблоне компонента. Объедините <picture> (для WebP) с srcset внутри — и вы получите одновременно правильный формат и правильный масштаб для каждого устройства.

Проверка и типичные ошибки

После внедрения прогоните страницы через PageSpeed Insights и Lighthouse и посмотрите на рекомендации «Properly size images», «Serve images in next-gen formats», «Defer offscreen images» — они должны уйти в зелёную зону.

Частые ошибки, которые сводят оптимизацию на нет:

• lazyload повешен на LCP-элемент — ухудшается, а не улучшается скорость;
• нет width/height — растёт CLS, страница «прыгает» при загрузке;
• WebP отдаётся без fallback — краулеры и старые клиенты видят битую картинку;
• ресайз-кэш /upload/resize_cache/ не чистится при массовой замене фото и занимает десятки гигабайт;
• оригиналы весом 2–3 МБ так и остаются в вёрстке, потому что вывели SRC напрямую.

Отдельно проверьте, что WebP-версии и ресайзы отдаются с корректными заголовками кэширования (Cache-Control, Expires), иначе выигрыш съедят повторные загрузки.

Итог

Ускорение изображений в Битрикс складывается из четырёх шагов: ресайз под реальный размер блока через CFile::ResizeImageGet(), перевод в WebP с fallback через <picture>, нативный loading="lazy" для всего, кроме первого экрана, и адаптивный srcset. Вместе они снимают основную массу веса страницы и напрямую улучшают LCP и CLS.

Работы затрагивают шаблоны компонентов, конфигурацию веб-сервера и композит — здесь легко испортить вёрстку или сломать fallback, если действовать наугад. Если нужен предсказуемый результат по Core Web Vitals без экспериментов на проде, мы в B2Bsite проводим ускорение каталога комплексно: от аудита картинок до настройки кэша и композита.