Оптимизация изображений на сайте: WebP, сжатие, lazy loading

Почему именно изображения чаще всего виноваты в медленной загрузке

При аудите скорости практически любого сайта на CMS изображения оказываются самой тяжёлой частью страницы — заметно тяжелее HTML, CSS и JavaScript вместе взятых. Одна фотография в высоком разрешении, загруженная «как есть» с камеры или смартфона без какой-либо обработки, легко весит 3–8 мегабайт, тогда как вся остальная страница вместе с шрифтами и скриптами часто укладывается в несколько сотен килобайт.

Проблема усугубляется тем, что на типичной странице интернет-магазина или каталога изображений может быть не одно, а десятки — карточки товаров, миниатюры, баннеры, иконки. Даже умеренно тяжёлые файлы, помноженные на такое количество, превращают страницу в мегабайты трафика, которые пользователю с мобильным интернетом или ограниченным тарифным планом приходится ждать заметно дольше, чем текстовый контент той же страницы.

Хорошая новость в том, что изображения — одна из самых благодарных областей для оптимизации именно потому, что современные форматы и техники дают заметный выигрыш без визуально различимой потери качества, в отличие от, например, попыток сократить сам код сайта, где эффект обычно куда скромнее относительно затраченных усилий.

WebP и AVIF против JPEG и PNG: реальная разница в цифрах

JPEG и PNG — форматы, спроектированные десятилетия назад под совершенно другие условия сети и экраны. JPEG хорошо сжимает фотографии с плавными переходами цвета ценой потери части данных, PNG сохраняет изображение без потерь, что удобно для графики с чёткими границами и прозрачностью, но даёт заметно больший размер файла для фотографий.

WebP, разработанный Google, обычно даёт файлы на 25–35% меньше по размеру, чем JPEG сопоставимого визуального качества, и поддерживает прозрачность, как PNG, но с заметно лучшим сжатием. AVIF, более новый формат на основе кодека AV1, идёт ещё дальше — на части изображений выигрыш по размеру относительно JPEG превышает 50%, хотя кодирование в AVIF занимает больше времени на стороне сервера или инструмента сборки, что имеет значение при массовой пакетной конвертации большого каталога изображений.

Поддержка обоих современных форматов в актуальных версиях всех основных браузеров сегодня достаточно широка для практического использования, но полностью полагаться только на них рискованно — часть посетителей может заходить с устаревших браузеров или встроенных webview-приложений с неполной поддержкой. Правильная практика — использовать тег picture с несколькими источниками, чтобы браузер сам выбрал наиболее подходящий поддерживаемый формат, откатываясь на JPEG или PNG как universally совместимый резервный вариант.

<picture>
  <source srcset="photo.avif" type="image/avif">
  <source srcset="photo.webp" type="image/webp">
  <img src="photo.jpg" alt="Описание изображения" width="800" height="600">
</picture>

Как конвертировать изображения на практике

Для разовой конвертации уже загруженных на сервер изображений удобна консольная утилита cwebp из пакета libwebp — она берёт исходный JPEG или PNG и создаёт WebP-версию с указанным уровнем качества, который можно подобрать под конкретный тип контента.

cwebp -q 80 original.jpg -o original.webp

Значение -q 80 — разумная отправная точка для фотографий: заметно меньший размер файла по сравнению с оригиналом при визуально неотличимом от исходника качестве на обычном экране. Для массовой конвертации целой директории изображений эту команду легко обернуть в простой shell-скрипт с циклом по файлам, либо воспользоваться пакетным режимом самой утилиты.

for f in *.jpg; do
  cwebp -q 80 "$f" -o "${f%.jpg}.webp"
done

Для сайтов на популярных CMS чаще удобнее не заниматься ручной конвертацией через консоль, а подключить соответствующий плагин или встроенную функцию, которая автоматически создаёт WebP-версию (а иногда и AVIF) при каждой новой загрузке изображения через административную панель, отдавая нужный формат конкретному браузеру автоматически без ручного вмешательства в будущем.

Адаptivные изображения: зачем мобильному телефону десктопная картинка

Ещё одна массовая проблема — сайт отдаёт одно и то же изображение в полном разрешении всем посетителям независимо от размера их экрана. Баннер шириной 1920 пикселей, спроектированный для широкого десктопного монитора, при открытии на телефоне с экраном в 390 пикселей визуально сжимается браузером до нужного размера, но по сети всё равно передаётся полный файл — пользователь платит трафиком и временем ожидания за пиксели, которые физически не поместятся на его экране.

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

<img
  src="banner-800.jpg"
  srcset="banner-400.jpg 400w, banner-800.jpg 800w, banner-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 800px"
  alt="Баннер" width="800" height="450">

Атрибут sizes здесь описывает, какую реальную ширину займёт изображение на экране в зависимости от ширины окна просмотра (viewport) — на экране уже 600 пикселей изображение растягивается на всю ширину (100vw), в остальных случаях занимает фиксированные 800 пикселей. Именно эта информация позволяет браузеру заранее, ещё до получения самого изображения, выбрать из srcset ближайший подходящий по размеру вариант и не загружать остальные впустую.

Lazy loading: не грузить то, что пользователь ещё не видит

На длинной странице каталога с десятками карточек товаров или в ленте статей с иллюстрациями большая часть изображений физически находится ниже видимой области экрана в момент первой загрузки страницы. Загружать их все сразу — тратить трафик и время впустую, если пользователь вообще не долистает страницу до конца.

<img src="product.jpg" loading="lazy" alt="Товар" width="400" height="400">

Атрибут loading="lazy" — встроенная функция современных браузеров без необходимости в сторонних JavaScript-библиотеках: браузер сам откладывает загрузку изображения до момента, когда оно приближается к видимой области экрана при прокрутке, экономя трафик и ускоряя первичную отрисовку страницы. Поддержка этого атрибута сегодня достаточно широка среди современных браузеров, чтобы использовать его как основной, беспроигрышный по стоимости внедрения метод.

До появления нативного атрибута эту же задачу решали сторонние JavaScript-библиотеки, отслеживающие положение элементов на странице через обработчики событий скролла — такой подход требовал дополнительной загрузки самого скрипта и был заметно тяжелее для производительности, чем встроенный в браузер механизм. Сегодня подключать отдельную библиотеку ради lazy loading изображений имеет смысл лишь в редких случаях специфичной анимации появления контента, а не для базовой экономии трафика, которую полностью закрывает нативный атрибут.

Критически важное правило — никогда не применять lazy loading к изображениям, которые видны сразу при открытии страницы без прокрутки, в первую очередь к главному герою-баннеру или первому изображению товара на карточке. Именно такое изображение чаще всего оказывается тем самым LCP-элементом страницы (Largest Contentful Paint), и искусственная задержка его загрузки через lazy loading напрямую ухудшает эту метрику, вместо того чтобы что-либо ускорить — браузер вынужден сначала определить положение элемента на странице, и только затем инициировать его загрузку, теряя драгоценное время на самом важном изображении страницы.

Практическое правило разделения: для первого экрана (above the fold) — обычная загрузка без атрибута lazy, а лучше с явным атрибутом fetchpriority="high" для действительно ключевого изображения; для всего, что находится ниже первого экрана, — loading="lazy" без исключений. Определить границу первого экрана достаточно приблизительно один раз для типового макета страницы — драматической точности здесь не требуется.

Связь с Core Web Vitals: как это измеряется на практике

Оптимизация изображений напрямую влияет на две из трёх метрик Core Web Vitals. LCP (Largest Contentful Paint) измеряет, через сколько времени после начала загрузки на экране появляется самый крупный видимый элемент — чаще всего это как раз главное изображение страницы; более лёгкий файл в современном формате загружается быстрее, что напрямую сокращает время до LCP. Подробный разбор всех трёх метрик и того, что на них влияет, — в отдельной статье про Core Web Vitals.

CLS (Cumulative Layout Shift) измеряет, насколько сильно элементы страницы «прыгают» уже после того, как пользователь начал её просматривать. Самая частая причина роста CLS, связанная именно с изображениями, — отсутствие явно заданных атрибутов width и height: пока изображение ещё не загрузилось, браузер не знает его реальных пропорций и резервирует под него нулевую высоту, а когда файл наконец загружается, вся остальная вёрстка страницы резко сдвигается вниз, освобождая место под неожиданно появившийся блок.

Явное указание width и height у каждого тега img — простое и почти бесплатное по трудозатратам решение этой проблемы: браузер заранее знает соотношение сторон изображения и резервирует под него правильную область на странице ещё до того, как файл фактически загрузился, независимо от того, каким итоговым размером на экране это изображение будет выведено через CSS. Современный подход — задавать это соотношение и через CSS-свойство aspect-ratio, что особенно удобно для адаптивных сайтов, где итоговый размер блока меняется в зависимости от ширины экрана.

Формат SVG для графики, которая не является фотографией

Логотипы, иконки и простая векторная графика — отдельная категория, для которой ни JPEG, ни WebP, ни AVIF обычно не являются лучшим выбором. Формат SVG хранит изображение не как сетку пикселей, а как набор математических инструкций для отрисовки линий и фигур, из-за чего файл остаётся компактным независимо от размера вывода на экране, а само изображение масштабируется без какой-либо потери чёткости на экранах любой плотности пикселей.

Практическая граница выбора простая: если изображение — фотография или сложная иллюстрация с множеством оттенков и плавными переходами цвета, современный растровый формат вроде WebP или AVIF почти всегда эффективнее по размеру файла. Если изображение — логотип, иконка или простая геометрическая графика с ограниченным числом цветов, SVG обычно выигрывает и по размеру, и по универсальности использования на разных фонах и в разных размерах без необходимости готовить отдельные файлы под каждое разрешение.

Инструменты сжатия без консоли: онлайн-сервисы и плагины CMS

Не у каждого администратора сайта есть доступ к консоли сервера или желание разбираться с утилитами вроде cwebp — для разовой оптимизации небольшого числа изображений вполне достаточно бесплатных онлайн-инструментов вроде Squoosh (разработка Google, работает прямо в браузере без загрузки файлов на сторонний сервер) или TinyPNG, которые дают наглядное сравнение исходного и сжатого файла с ползунком качества и мгновенным визуальным контролем результата.

Для WordPress, Bitrix и других популярных CMS существуют готовые плагины, которые встраивают конвертацию в WebP и сжатие прямо в процесс загрузки медиафайлов через административную панель — редактор сайта просто загружает изображение как обычно, а плагин в фоне создаёт оптимизированную версию и подменяет ссылки на неё в выводе страниц, не требуя от человека вообще ничего знать про форматы и утилиты командной строки.

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

Автоматизация вместо ручной обработки каждого файла

На активно обновляемом сайте — интернет-магазине с постоянно растущим каталогом, новостном ресурсе с ежедневными публикациями — ручная конвертация и сжатие каждого нового изображения перед загрузкой практически нереалистична и рано или поздно будет забыта в спешке публикации очередного материала.

Правильная практика — настроить автоматизацию на уровне самой CMS или сборки проекта: плагин или встроенный модуль, который автоматически создаёт WebP (а по возможности и AVIF) версию при каждой загрузке изображения через административную панель, приводит размер к разумному максимуму по ширине и высоте вместо хранения оригинала в исходном разрешении с камеры, и отдаёт корректный формат конкретному браузеру автоматически.

Для проектов с собственной сборкой фронтенда эту же задачу решают инструменты вроде sharp или imagemin, встроенные в пайплайн сборки — изображения обрабатываются один раз на этапе деплоя, а не при каждом запросе пользователя, что снимает нагрузку с самого сервера и гарантирует одинаковый результат для всех изображений проекта без исключений, забытых при ручной обработке.

Роль сервера и CDN в скорости отдачи изображений

Даже идеально сжатое и правильно адаптированное изображение всё равно должно физически дойти до браузера пользователя, и здесь начинает играть роль удалённость сервера от аудитории и производительность самого диска, с которого файл читается. Если аудитория сайта географически распределена, а сервер физически расположен в одном регионе, для пользователей на другом конце страны или за рубежом задержка на передачу даже небольшого файла становится заметной просто из-за расстояния и числа промежуточных сетевых узлов.

Именно для этого сценария CDN с кэшированием статических файлов на множестве географически распределённых узлов даёт заметный эффект: изображение один раз попадает на ближайший к конкретному пользователю узел и дальше отдаётся оттуда без обращения к исходному серверу — подробнее о том, когда это оправдано для конкретного сайта, разобрано в отдельной статье про CDN. Для сайта с преимущественно локальной или региональной аудиторией, физически близкой к серверу, эффект от CDN именно для изображений может оказаться менее заметным, чем сама оптимизация форматов и размеров.

Дисковая подсистема сервера тоже имеет значение при большом каталоге изображений и высокой посещаемости: NVMe против обычного SSD или тем более HDD напрямую влияет на скорость чтения множества файлов одновременно при параллельных запросах разных посетителей — этот аспект подробно разобран в статье про выбор конфигурации VPS.

Итог: чек-лист оптимизации изображений

Переведите фотографии и сложные изображения в WebP (и по возможности AVIF) с резервным вариантом в JPEG через тег picture, сохраняя SVG для логотипов, иконок и простой векторной графики. Добавьте srcset и sizes для изображений, которые выводятся в разных размерах на разных устройствах, чтобы мобильные пользователи не скачивали десктопную версию файла.

Проставьте loading="lazy" всем изображениям ниже первого экрана без исключений, и убедитесь, что герой-баннер и другие элементы первого экрана загружаются немедленно, без lazy loading. Явно указывайте width и height (или aspect-ratio через CSS) у каждого изображения, чтобы устранить сдвиги вёрстки при загрузке и снизить CLS.

Настройте автоматическую обработку новых изображений при загрузке через CMS, чтобы не зависеть от того, вспомнит ли редактор сайта вручную сжать очередную фотографию перед публикацией. Проверьте результат через PageSpeed Insights — инструмент прямо укажет оставшиеся тяжёлые изображения и конкретные рекомендации по каждому из них. Если нужна помощь с настройкой автоматической оптимизации изображений на вашем сервере — оставьте заявку внизу страницы.