Откройте любую карточку товара и посмотрите, что грузится дольше всего. Почти всегда это изображения: галерея, превью, баннеры. На магазине они составляют львиную долю веса страницы, и именно они чаще всего роняют скорость и портят Core Web Vitals. При этом JPEG и PNG — форматы прошлого десятилетия, а современные WebP и AVIF сжимают то же самое в разы легче.
Проблема в том, что «просто переключить формат» звучит легко, а на практике всплывают fallback для старых браузеров, конвертация, кэш, ленивая загрузка и обмен с 1С. В этой статье разберём, как внедрить WebP и AVIF в магазине на 1С-Битрикс без боли и без риска, что у части посетителей пропадут картинки. Системно скорость мы поднимаем услугой оптимизации JavaScript, CSS и изображений (WebP, lazy load).
Коротко
- Изображения — самая тяжёлая часть страницы магазина; WebP и AVIF сжимают их в разы сильнее JPEG/PNG.
- Внедряйте по принципу «добавить, а не заменить»: новые форматы через picture с fallback на JPEG.
- Конвертируйте заранее с кэшем для большого каталога; связывайте генерацию с обменом с 1С.
- Не грузите LCP-картинку лениво, дополняйте новые форматы адаптивными размерами (srcset) — тогда Core Web Vitals заметно улучшаются.
Почему изображения — главный тормоз магазина
На типичной странице магазина изображения весят больше, чем весь остальной контент вместе взятый. Каталог — это витрина, а витрина — это картинки: превью в списке, галерея в карточке, баннеры на главной. Каждая лишняя сотня килобайт умножается на десятки изображений и на каждого посетителя.
Тяжёлые картинки бьют по двум фронтам сразу: пользователь ждёт отрисовки и уходит, а поисковик снижает оценку скорости и позиции. Причём главная картинка карточки часто и есть тот элемент, по которому считается LCP — ключевая метрика скорости. Поэтому оптимизация изображений — одна из самых окупаемых работ по производительности.
WebP и AVIF: в чём разница
Оба формата решают одну задачу — весить меньше при том же качестве, — но с разными компромиссами.
| Критерий | WebP | AVIF | JPEG/PNG |
|---|---|---|---|
| Сжатие | Сильное | Очень сильное | Слабое |
| Поддержка браузерами | Почти повсеместная | Широкая, чуть уже | Повсеместная |
| Скорость кодирования | Быстрая | Медленнее | Быстрая |
| Прозрачность | Есть | Есть | PNG — да, JPEG — нет |
| Роль | Основной формат | Лучший, где поддержан | Fallback и исходник |
Практичный вывод: отдавайте AVIF там, где он поддержан, WebP как основной формат, а JPEG/PNG держите запасным. Не нужно выбирать один — тег picture позволяет перечислить все три по приоритету.
Стратегия «добавить, а не заменить»
Главный принцип безболезненного внедрения — не удалять старые форматы, а добавлять новые поверх. Браузер, который умеет AVIF или WebP, получит лёгкую версию; браузер, который не умеет, — привычный JPEG. Так вы выигрываете в скорости без риска, что у части посетителей картинки перестанут открываться.
Тег picture и fallback
Стандартный и безопасный способ отдать современные форматы — HTML-тег picture. Внутри него несколько source с разными форматами и один img как запасной вариант. Браузер идёт по списку сверху вниз, берёт первый поддерживаемый формат, а если ни один не подошёл — грузит img.
Порядок обычно такой: сначала AVIF, затем WebP, затем img с JPEG. Такой подход не требует определять браузер на сервере и работает на стороне клиента по стандарту. В 1С-Битрикс вывод picture добавляют в шаблоны компонентов, которые показывают изображения, — об этом ниже в разделе про внедрение.
Конвертация: на лету или заранее
Лёгкие версии нужно откуда-то взять — их генерируют из исходников. Есть два подхода, и оба рабочие.
- Заранее (предгенерация). Версии в WebP/AVIF создаются при загрузке товара или пакетно. Минимум нагрузки при отдаче, предсказуемость, но нужно хранить копии.
- На лету. Версия создаётся при первом запросе и кэшируется. Экономит место, удобна для динамики, но нагружает сервер и обязательно требует кэш.
Для крупного каталога чаще выбирают предгенерацию с кэшем на диске: тяжёлое кодирование (особенно AVIF) не должно происходить в момент отдачи страницы. Ключевое в обоих подходах — кэшировать результат, чтобы не пересчитывать одно и то же. Тяжёлые фоновые задачи удобно выносить на агентов Битрикс и отдельные процессы, чтобы не мешать основному трафику; это перекликается с практиками CI/CD и деплоя, где генерацию ассетов включают в сборку.
Ленивая загрузка и первый экран
Ленивая загрузка (lazy load) откладывает загрузку изображений, пока они не понадобятся, — и это отлично для галереи и списков товаров. Но с ней есть важная тонкость: её нельзя применять к картинкам первого экрана, особенно к LCP-изображению.
Если отложить лениво именно главную картинку, вы отложите тот самый элемент, по которому считается скорость, — и ухудшите показатели вместо улучшения. Правильная схема:
- Приоритетная загрузка. Главная картинка карточки и баннеры первого экрана грузятся обычным образом, без lazy.
- Ленивая загрузка. Всё, что ниже сгиба: галерея, превью в списке, картинки в подвале.
- Резервирование места. Заданные width и height, чтобы не прыгала вёрстка (CLS).
Адаптивные размеры: srcset и sizes
Мало отдать лёгкий формат — важно ещё не грузить картинку 2000px туда, где по факту нужно 400px. Здесь помогают атрибуты srcset и sizes: они описывают несколько размеров одного изображения, и браузер выбирает подходящий под экран и плотность пикселей.
Новый формат и адаптивные размеры дополняют друг друга: кодек экономит на способе сжатия, а srcset — на количестве пикселей. Вместе они дают максимальный выигрыш. В 1С-Битрikс размеры-превью удобно готовить штатными средствами масштабирования изображений и складывать в тот же picture вместе с форматами.
Связка с обменом с 1С
В магазине картинки товаров обычно приходят из 1С обменом — как исходники в JPEG или PNG. Ошибка — пытаться усложнять сам обмен генерацией форматов. Правильная архитектура разводит слои:
- Обмен кладёт исходник. Из 1С приходит JPEG/PNG и сохраняется как есть.
- Слой генерации создаёт версии. Отдельная логика на стороне сайта делает WebP/AVIF из исходника.
- Кэш хранит результат. Лёгкие версии кэшируются и переиспользуются.
- Обновление по триггеру. При изменении картинки товара версии пересоздаются.
Так обмен не усложняется, а оптимизация форматов работает поверх него автоматически. Если каталог большой и обмен и так тяжёлый, генерацию форматов особенно важно держать отдельным процессом — эта тема пересекается со статьёй про ускорение обмена с 1С при большом каталоге.
Влияние на Core Web Vitals
Переход на современные форматы напрямую бьёт по ключевым метрикам скорости:
- LCP. Главная картинка легчает в разы и отрисовывается быстрее — основная метрика улучшается заметнее всего.
- Общий вес страницы. Меньше трафика, быстрее загрузка на мобильных и медленных сетях.
- CLS. В связке с заданными размерами и резервированием места вёрстка не прыгает.
- Ощущаемая скорость. Страница «оживает» раньше, что снижает отказы.
Скорость каталога держится не только на картинках, но и на кэше и инфраструктуре. Изображения хорошо сочетаются с правильным хостингом на BitrixVM и композитным кэшированием: статика отдаётся мгновенно, а лёгкие форматы уменьшают то, что вообще нужно передать.
Внедрение в 1С-Битрикс пошагово
Внедрять форматы не нужно «во всём сайте сразу» — вывод изображений сосредоточен в нескольких местах. Порядок такой:
- Найдите точки вывода. Карточка, список товаров, галерея, баннеры — где показываются картинки.
- Добавьте слой генерации. Логика создания WebP/AVIF из исходника с кэшем на диске.
- Замените img на picture. В шаблонах компонентов выводите picture с AVIF, WebP и fallback.
- Настройте lazy аккуратно. Ленивая загрузка ниже сгиба, приоритетная — для LCP-картинки.
- Добавьте адаптивные размеры. srcset/sizes для превью под разные экраны.
- Свяжите с обменом. Пересоздание версий при обновлении картинок из 1С.
- Измерьте результат. Проверьте LCP и вес страниц до и после на реальных страницах.
Частые ошибки
- Замена вместо добавления. Убрали JPEG — у старых браузеров пропали картинки.
- Нет кэша при конвертации на лету. Сервер пересчитывает форматы на каждый запрос и падает под нагрузкой.
- Lazy на LCP-картинке. Отложили именно то изображение, по которому считается скорость.
- Нет размеров у img. Вёрстка прыгает при загрузке, страдает CLS.
- Отдают один огромный размер. Картинка 2000px там, где нужно 400px, — трафик впустую.
- Генерация внутри обмена. Тяжёлое кодирование тормозит выгрузку каталога из 1С.
- Внедрили и не измерили. Нет замеров до/после — непонятно, что дало эффект.
Чек-лист внедрения
- Форматы добавлены, не заменены. AVIF/WebP через picture, JPEG как fallback.
- Генерация с кэшем. Лёгкие версии создаются заранее и кэшируются.
- Lazy настроен верно. Ниже сгиба — лениво, LCP-картинка — приоритетно.
- Адаптивные размеры. srcset/sizes отдают нужный размер под экран.
- Размеры заданы. width/height у изображений против скачков вёрстки.
- Связка с обменом. Версии пересоздаются при обновлении картинок из 1С.
- Результат измерен. LCP и вес страниц проверены до и после.
Вывод
WebP и AVIF — одна из самых окупаемых оптимизаций скорости магазина: изображения весят больше всего, а новые форматы сжимают их в разы. Внедрять их не больно, если действовать по принципу «добавить, а не заменить»: picture с fallback на JPEG, генерация с кэшем, ленивая загрузка ниже сгиба и адаптивные размеры.
В 1С-Битрикс это точечная работа по нескольким шаблонам компонентов плюс отдельный слой генерации, связанный с обменом с 1С. Сделайте это аккуратно — и LCP, вес страниц и позиции в поиске пойдут вверх, а посетители перестанут ждать, пока прогрузится витрина.
