Картинка шириной 1920 пикселей на странице загружается целиком и у владельцев телефонов, а на экране ужимается до 390 пикселей — в пять раз больше трафика и более медленная загрузка без всякой пользы. srcset позволяет браузеру выбрать версию под экран, но только при условии, что эти версии вы подготовили.
Почему одной картинки мало
Показатель LCP в Core Web Vitals — это, как правило, крупное изображение на первом экране. Если отдать телефону файл шириной 1920 и весом 400 КБ, LCP редко укладывается в 2,5 секунды; версия шириной 480 и весом 40 КБ по тому же каналу грузится на порядок быстрее. Сигнал Google о качестве страницы считывает это число напрямую.
С другой стороны, картинка шириной 768 на большом десктопном мониторе выглядит мягкой. Отсюда и несколько размеров, из которых выбирает сам браузер.
Практичная таблица брейкпоинтов
Опорой служит ширина, в которой изображение выводится на странице, а не окно просмотра. Для двух самых частых случаев — баннеров на всю ширину и иллюстраций в статье:
- Изображения на всю ширину (главный блок, баннеры): 480, 768, 1200, 1920. Телефон, планшет, ноутбук, большой монитор.
- Иллюстрации в статье (колонка контента до 800): 400, 800, 1200; версия 1200 обслуживает экраны 1,5x–2x.
- Миниатюры и карточки (выводятся шириной около 300): 300 и 600.
Больше ступеней — не значит лучше. Каждая — это ещё один экспорт и ещё один файл на хранение, а браузеры прощают неточное попадание, поэтому оптимален шаг в 1,5–2 раза. Четыре ступени закрывают больше девяти из десяти сочетаний устройств.
Нужны ли версии 2x
Retina и большинство телефонных экранов работают с плотностью 2x–3x: чтобы картинка шириной 400 выглядела чёткой, нужно 800 пикселей. Крупные ступени из таблицы уже играют роль версий 2x для мелких — 768 это 2x для телефона шириной 390, а 1200 — 2x для колонки шириной 600.
Так что отдельный набор «@2x» не нужен. Выдерживайте между ступенями шаг примерно вдвое, и браузер сам выберет более крупную версию по плотности.
Формат: сначала WebP, JPG про запас
При одинаковом качестве WebP на 25–35 % легче JPG, и его поддерживают все современные браузеры. Экспортируйте WebP для каждого размера и оставьте запасной JPG через элемент picture для старых браузеров; если для вашей аудитории браузеры до 2020 года уже не важны, достаточно одного WebP.
AVIF весит ещё меньше, но кодируется в браузере заметно дольше, а на больших пачках это ощутимо. Все компромиссы подробно разобраны в материале AVIF, WebP или JPEG.
Пакетный экспорт всего набора
Загрузите исходники в инструмент Пакетная обработка изображений и делайте по одному запуску на каждую ступень, меняя ширину и суффикс:
- Размер: ширина 480, «Увеличивать маленькие изображения» выключено, результат WebP с качеством 80 %, суффикс -480.
- Те же настройки для 768 с суффиксом -768; затем 1200; затем 1920.
- Для запасного JPG переключите результат на JPG, суффиксы оставьте и запустите ещё раз.
Каждый запуск занимает секунды, и в ZIP уже лежат hero-480.webp, hero-768.webp и так далее — остаётся положить их в папку с изображениями. Не включайте увеличение, чтобы оригинал в 1000 пикселей не растянулся до 1920.
Чтобы увидеть разницу в весе по ступеням на одном изображении, откройте один файл в инструменте Изменение размера изображений.
Пишем HTML
Для изображения на всю ширину:
<img src="hero-1200.jpg"
srcset="hero-480.webp 480w, hero-768.webp 768w, hero-1200.webp 1200w, hero-1920.webp 1920w"
sizes="100vw" width="1920" height="1080" alt="...">Для иллюстраций в статье задавайте sizes по реальной ширине, например sizes="(max-width: 840px) 100vw, 800px". Всегда указывайте width и height: тогда браузер заранее резервирует место, и страница не «прыгает».
Когда это сделано, добавьте советы по отложенной загрузке и сжатию из материала как ускорить загрузку изображений — и часть оценки производительности, связанная с картинками, практически выбрана полностью.