Каталог интернет-магазина — это сотни изображений на странице. Если каждое отдаётся в одном большом размере, мобильный пользователь скачивает мегабайты, которые ему не нужны: его экран физически не покажет картинку в исходном разрешении. Итог — медленная загрузка, недовольные посетители и проседающие показатели скорости, которые к тому же влияют на позиции в поиске.
Эта статья — практический разбор адаптивных изображений на 1С-Битрикс: как устроены атрибуты srcset и sizes, когда нужен тег picture, как подключить WebP и ленивую загрузку, как готовить варианты картинок штатным resize-модулем и что всё это даёт для Core Web Vitals. Скорость каталога — комплексная задача, поэтому по ходу мы затронем аудит и оптимизацию как способ найти, где именно теряется производительность.
Коротко
- srcset даёт браузеру набор размеров, sizes подсказывает, какого размера картинка на странице; работают только вместе.
- Для масштабирования одного фото хватает srcset; для смены формата или кропа нужен picture с source.
- WebP и srcset складываются: один уменьшает пиксели, другой — вес; экономия максимальна вместе.
- Варианты картинок в 1С-Битрикс готовит штатный resize с кэшем; ширину и высоту задают всегда, чтобы не было CLS.
Почему одна картинка на всех — это дорого
Долгое время сайты отдавали одно изображение всем устройствам — большое, «с запасом». На десктопе с широким экраном это оправдано, но телефон получает тот же тяжёлый файл и вынужден его скачивать и уменьшать. Пользователь платит за это трафиком и временем ожидания, а сайт — позициями: скорость давно входит в факторы ранжирования.
Адаптивные изображения решают проблему в корне: браузеру дают несколько вариантов одной картинки, и он выбирает подходящий под конкретный экран. Телефон получает лёгкую версию, десктоп — крупную, экран высокой плотности — вариант повышенного разрешения. Никто не качает лишнего, и картинка при этом не выглядит размытой. Для каталога с сотнями изображений эффект огромен.
Как браузер выбирает изображение
Чтобы правильно писать srcset и sizes, нужно понимать логику браузера. Он учитывает два фактора: сколько места картинка займёт на странице и какова плотность пикселей устройства. Обычный экран имеет плотность 1, у современных смартфонов и «ретины» она выше — им для чёткости нужен файл с большим числом пикселей.
Браузер берёт из sizes предполагаемую ширину картинки на странице, умножает на плотность экрана и выбирает из srcset вариант, ближайший сверху к этому числу. Ключевой момент: решение принимается до полной загрузки страницы, на раннем этапе разбора HTML. Поэтому подсказки должны быть в разметке сразу и быть точными — если sizes врёт, браузер выберет неоптимальный файл.
srcset: варианты по ширине
Атрибут srcset перечисляет доступные версии изображения с указанием их реальной ширины в пикселях через дескриптор w. Например, для товарной картинки готовят набор ширин под сетку каталога — маленькую для плотной сетки на мобильном, среднюю для планшета, крупную для десктопа и увеличенного просмотра.
Несколько практических принципов:
- Указывайте реальную ширину. Дескриптор
w— это фактическое число пикселей файла, а не размер на экране. - Стройте набор под сетку. Ширины подбирают под то, как картинка реально показывается в каталоге, а не «на глаз».
- Не плодите лишнего. Трёх-четырёх ширин обычно достаточно; десяток вариантов усложняет генерацию без заметной пользы.
- Оставляйте src как запасной. Обычный
srcнужен для браузеров без поддержки и как fallback.
sizes: подсказка о размере на странице
Без sizes атрибут srcset с дескрипторами w работает вполсилы: браузер по умолчанию считает, что картинка занимает всю ширину экрана, и часто грузит вариант крупнее нужного. sizes исправляет это, описывая, какого размера картинка будет при разной ширине вьюпорта.
Синтаксис — это условия по ширине экрана и соответствующие им размеры картинки, обычно в единицах вьюпорта или пикселях. Например, «на узких экранах картинка занимает половину ширины, на широких — четверть». Браузер читает это и точно рассчитывает, какой файл взять. Значения sizes должны соответствовать реальному CSS каталога: если по стилям на десктопе в ряду четыре товара, то и sizes должен отражать эту ширину. Расхождение верстки и sizes — частая причина того, что адаптивные картинки «не работают».
srcset и picture: когда что
Есть два инструмента адаптивных изображений, и путать их не стоит.
| Задача | Инструмент | Пример |
|---|---|---|
| Один снимок в разных размерах | img + srcset + sizes | Товарное фото в сетке каталога |
| Разные форматы | picture + source | WebP с запасным JPEG |
| Другой кроп для мобильных | picture + source (media) | Крупный план на телефоне, общий на десктопе |
| Смена содержания баннера | picture + source (media) | Вертикальный баннер для мобильных |
Правило простое: если меняется только размер одного и того же изображения — хватает img с srcset и sizes. Если меняется формат или само содержание (кроп, композиция) — нужен picture с несколькими source. В каталоге товаров подавляющее большинство случаев — первое, и усложнять там picture без нужды не стоит.
WebP и современные форматы
Оптимизация размера в пикселях через srcset — только половина дела. Вторая половина — вес файла при том же размере, и здесь помогают современные форматы. WebP при сопоставимом качестве весит заметно меньше привычных JPEG и PNG, а значит, страница грузится быстрее без потери в картинке.
Подключают WebP двумя способами: через picture с source type="image/webp" и запасным JPEG внутри, либо автоматической конверсией на стороне сервера с проверкой заголовков браузера. Второй путь удобнее для каталога: исходники хранятся как есть, а отдача в WebP происходит прозрачно там, где браузер это поддерживает. Важно оставлять запасной формат — не все окружения работают с WebP одинаково, и надёжность важнее пары процентов экономии. Эти оптимизации складываются с srcset: маленький по размеру и лёгкий по весу файл — идеал для мобильного каталога.
Ленивая загрузка и приоритеты
Каталог с сотнями картинок не должен грузить их все сразу — большую часть посетитель никогда не увидит, если не долистает. Ленивая загрузка через атрибут loading="lazy" откладывает загрузку изображений вне экрана до момента, когда они понадобятся. Это резко ускоряет первую отрисовку и экономит трафик.
Но есть важное исключение — главное изображение в верхней части экрана. Обычно это крупное фото товара или баннер, и именно оно чаще всего оказывается LCP-элементом — тем контентом, по загрузке которого измеряется скорость. Ему ленивую загрузку не ставят, наоборот — грузят приоритетно. Ошибка «ленивый LCP» встречается часто и заметно портит показатели: браузер откладывает как раз ту картинку, которую надо показать первой. Правильная расстановка приоритетов — ленивая загрузка для всего, кроме главного изображения экрана.
Резервирование места и CLS
Отдельная проблема — прыгающий макет. Пока картинка грузится, если для неё не зарезервировано место, контент под ней сдвигается в момент появления файла. Пользователь тянется нажать кнопку — и она уезжает. Эта метрика называется CLS (смещение макета) и входит в Core Web Vitals.
Лечится просто: у каждого изображения задают ширину и высоту в атрибутах или соотношение сторон через CSS. Тогда браузер заранее знает пропорции и резервирует место до загрузки файла — контент не прыгает. Это одна из самых дешёвых оптимизаций: буквально указание размеров у тегов, а эффект на стабильность страницы большой. В связке с srcset важно, чтобы соотношение сторон у всех вариантов совпадало, иначе резервирование собьётся.
Генерация вариантов в 1С-Битрикс
Готовить несколько размеров руками нереально для каталога — их генерируют автоматически. В 1С-Битрикс для этого есть штатное масштабирование изображений (resize) через API и компоненты: из одного загруженного файла создаются превью нужных размеров, которые кэшируются на диске.
На этой основе строят srcset: заранее определяют набор ширин под сетку каталога, а resize по запросу генерирует и кэширует каждый вариант. Первое обращение создаёт файл, дальше он отдаётся из кэша — нагрузка на генерацию разовая. Логику удобно вынести в помощник шаблона, который принимает картинку и набор ширин, а возвращает готовые srcset и sizes. Как аккуратно организовать такой код в современной архитектуре, мы разбираем в статье про D7 и ORM в 1С-Битрикс, а вынос повторяющейся логики в отдельный компонент — в материале про разработку собственного модуля.
Внедрение пошагово
Перевести каталог на адаптивные изображения можно поэтапно, не переписывая шаблон целиком.
- Определите точки вывода. Сетка каталога, карточка товара, баннеры — где какие размеры картинок реально нужны.
- Задайте наборы ширин. Под каждую точку — три-четыре ширины, соответствующие верстке.
- Настройте resize. Автогенерация вариантов из исходников с кэшированием.
- Соберите помощник шаблона. Функция, которая по картинке и набору ширин отдаёт srcset и корректный sizes.
- Подключите WebP. Через picture или серверную конверсию с запасным форматом.
- Расставьте приоритеты. Ленивая загрузка для всего, кроме главного изображения экрана.
- Зафиксируйте размеры. Ширина и высота у всех img, единое соотношение сторон вариантов.
Влияние на Core Web Vitals
Адаптивные изображения бьют сразу по нескольким метрикам Core Web Vitals — набору показателей, которые поисковики используют для оценки удобства:
- LCP (загрузка основного контента). Лёгкое главное изображение и приоритетная загрузка ускоряют показ ключевого контента.
- CLS (смещение макета). Заданные размеры картинок убирают прыжки страницы при загрузке.
- Общий вес страницы. Меньше скачанных байтов — быстрее интерактивность, особенно на мобильных.
Изображения — обычно самая тяжёлая часть страницы каталога, поэтому их оптимизация даёт наибольший прирост скорости при относительно небольших усилиях. Но это часть общей картины: скорость зависит ещё от кэша, композитного вывода и инфраструктуры, о которой мы пишем в материале про хостинг для 1С-Битрикс.
Частые ошибки
- srcset без sizes. Браузер грузит вариант крупнее нужного, экономия теряется.
- sizes не совпадает с версткой. Значения не соответствуют реальной ширине картинки в CSS.
- Ленивая загрузка на LCP. Главное изображение экрана откладывается и портит показатель загрузки.
- Нет размеров у img. Макет прыгает при загрузке, растёт CLS.
- WebP без запасного формата. В окружениях без поддержки картинки не показываются.
- Разные пропорции вариантов. Соотношение сторон в srcset не совпадает, резервирование места сбивается.
- Слишком много ширин. Десяток вариантов усложняет генерацию без ощутимой пользы.
Чек-лист и вывод
- srcset и sizes вместе. Каждая картинка каталога отдаёт набор ширин с корректной подсказкой размера.
- sizes соответствует CSS. Значения совпадают с реальной шириной картинки в верстке.
- WebP подключён. С запасным форматом для окружений без поддержки.
- Приоритеты расставлены. Ленивая загрузка везде, кроме главного изображения экрана.
- Размеры зафиксированы. Ширина и высота у всех img, единое соотношение сторон.
- Варианты генерирует resize. Автоматически из исходников с кэшированием.
- Проверено на метриках. LCP и CLS замерены до и после, эффект подтверждён.
Адаптивные изображения — одна из самых окупаемых оптимизаций скорости: относительно небольшая работа даёт заметный прирост, особенно на мобильных. Ключ — правильная связка srcset и sizes, соответствующая реальной верстке, современные форматы поверх неё, аккуратные приоритеты загрузки и зафиксированные размеры против прыжков макета. В 1С-Битрикс всё это опирается на штатный resize с кэшем, поэтому внедрение не требует ручной нарезки. Настройте адаптивные картинки — и каталог станет быстрее и для людей, и для поисковых систем. Продолжить тему стоит с материала про CI/CD и деплой для 1С-Битрикс, чтобы изменения в шаблон выкатывались безопасно.
