Оптимизация загрузки изображений для мобильного трафика: WebP, AVIF и lazy load
Изображения — обычно две трети веса страницы. На нестабильном мобильном интернете это разница между просмотром страницы и возвратом в выдачу.
Форматы: что выбирать в 2026 году
WebP поддерживается всеми актуальными браузерами и даёт примерно на четверть-треть меньший вес по сравнению с JPEG при сопоставимом качестве. Это безопасный формат по умолчанию для фотографий и графики.
AVIF сжимает ещё сильнее, особенно на фотографиях, но кодирование заметно медленнее, а поддержка в старых версиях браузеров и в некоторых встроенных вебвью хуже. Оптимальная схема — отдавать AVIF там, где браузер его поддерживает, с откатом на WebP и JPEG.
Реализуется через элемент picture с несколькими source: сначала AVIF, затем WebP, в конце обычный img с JPEG. Браузер сам выберет первый поддерживаемый вариант, никакого JavaScript для этого не нужно.
Размеры и адаптивная выдача
Самая частая ошибка — отдавать одно изображение шириной 2000 пикселей на все устройства. Мобильный экран отобразит его в 360 CSS-пикселей, а пользователь оплатит полный трафик.
Решение — атрибут srcset с несколькими версиями по ширине и sizes, описывающий, какую ширину изображение занимает в макете. Три-четыре варианта (например, 400, 800, 1200, 1600 пикселей) покрывают практически все случаи.
Всегда указывайте атрибуты width и height у изображений. Без них браузер не знает пропорции до загрузки и не резервирует место, из-за чего контент прыгает — это напрямую ухудшает метрику визуальной стабильности.
Lazy load: где применять и где нельзя
Атрибут loading="lazy" на img откладывает загрузку изображений вне видимой области. Это встроенная возможность браузера, отдельная библиотека не нужна и обычно только вредит.
Критически важное исключение: не ставьте lazy на главное изображение первого экрана. Оно почти всегда является элементом LCP, и отложенная загрузка напрямую ухудшает эту метрику. Наоборот, ему полезно указать fetchpriority="high".
Для каталогов правило простое: первые видимые карточки грузятся обычно, всё ниже — лениво. На узбекистанском мобильном трафике это ощутимо сокращает объём данных на первый экран.
Что оптимизировать помимо формата
Убирайте метаданные EXIF из фотографий: геолокация, модель камеры и превью занимают до нескольких десятков килобайт на файл и не нужны на сайте.
Подбирайте качество сжатия по типу изображения. Для фотографий товара 75–85 обычно неотличимо от оригинала, для скриншотов интерфейса лучше меньше сжатия или формат PNG с квантованием палитры.
Иконки и простую графику переводите в SVG. Векторный формат весит меньше растрового аналога, масштабируется без потерь и не требует нескольких версий под разные плотности экрана.
Изображения и поисковый трафик
Атрибут alt описывает содержимое изображения для незрячих пользователей и для поиска по картинкам. Пишите описательно и на языке текущей версии страницы: «женское пальто из шерсти, серое, вид спереди», а не набор ключей.
Имена файлов делайте осмысленными латиницей с дефисами: palto-sherstyanoe-seroe.webp. Файлы вида IMG_20260814_112233.jpg не несут никакой информации ни для поиска, ни для команды.
Для товарных изображений подключите поля image в разметке schema.org/Product — это увеличивает шанс расширенного сниппета. Для крупных каталогов имеет смысл отдельная карта изображений в sitemap.
Проверка на реальных условиях
Откройте DevTools, вкладка Network, включите профиль медленного соединения и посмотрите на суммарный вес и на время загрузки главного изображения. Это ближе к реальности узбекистанских мобильных сетей, чем офисный Wi-Fi.
В PageSpeed Insights смотрите пункты про современные форматы, размеры и офскрин-изображения — там же указан потенциальный выигрыш в килобайтах по каждому файлу.
После оптимизации сверьтесь с полевыми данными в отчёте Core Web Vitals в Search Console через две-четыре недели. Лабораторные тесты подтверждают правку, но подтверждает результат только поле.