Оптимизация изображений для SEO в 2026: WebP, AVIF, lazy load и правило размеров

Изображения — причина плохого LCP в большинстве случаев, которые мы видим на аудитах. Типичный сайт на WordPress везёт 2–4 МБ картинок на странице там, где PageSpeed Insights рекомендует уложиться в 300–500 КБ. При этом визуальное качество после оптимизации почти не страдает — разница заметна разве что при сравнении вплотную на экране 4K. А разница в скорости загрузки — 3–8 секунд на мобильном интернете.

Разберём по порядку: какой формат выбрать, как сжимать, как правильно прописать размеры и атрибуты загрузки — с конкретными командами и цифрами.

Форматы: что выбрать в 2026

Три формата, которые актуальны сейчас:

JPEG — ветеран с 30-летней историей. Поддержка 100%, но коэффициент сжатия хуже современных форматов. Файл 200 КБ в JPEG = примерно 80 КБ в WebP при том же визуальном качестве. Использовать JPEG сегодня — значит платить за трафик и скорость вдвое больше нужного.

WebP — разработан Google в 2010 году, поддержка браузерами достигла 96%+ к 2026 году. Обеспечивает на 25–35% меньший размер файла по сравнению с JPEG при сопоставимом качестве. Поддерживает прозрачность (как PNG), анимацию (как GIF). В большинстве случаев — оптимальный выбор по соотношению поддержка/сжатие.

AVIF — наследник HEIC, основан на кодеке AV1. Поддержка браузерами достигла 90%+ в 2025 году (Safari добавил в версии 16). Сжатие на 40–50% лучше JPEG, на 15–20% лучше WebP. Для изображений с плавными градиентами (фото, иллюстрации) — даёт ощутимый выигрыш. Минус: кодирование значительно медленнее WebP, что важно для систем с автоматической обработкой изображений.

Формат	Поддержка браузеров	Размер vs JPEG	Прозрачность	Скорость кодирования
JPEG	100%	—	Нет	Быстро
WebP	96%+	−25–35%	Да	Быстро
AVIF	90%+	−40–50%	Да	Медленно

Практическое правило для 2026: используйте WebP как основной формат для всего нового контента. Для критичных изображений (hero-баннеры, LCP-кандидаты) попробуйте AVIF через тег <picture> с fallback на WebP. JPEG оставляйте только там, где конвертация невозможна технически.

Как сжимать правильно

Конвертация сама по себе не гарантирует результат — важна настройка quality. При quality=100 WebP будет даже тяжелее JPEG. При quality=60 большинство пользователей не заметят разницы.

Конкретные инструменты и команды:

cwebp (официальный конвертер Google, устанавливается через пакетный менеджер):

cwebp -q 80 input.jpg -o output.webp

Quality 75–85 — оптимальная зона для фотографий. Для иконок и иллюстраций с плоским цветом можно поставить 65–70.

Squoosh CLI (от Google, работает через Node.js):

npx @squoosh/cli --webp '{"quality":82}' images/*.jpg

Позволяет пакетно обработать папку и задать разные параметры для WebP и AVIF в одной команде.

avifenc (для AVIF):

avifenc --min 20 --max 35 input.png output.avif

Параметры min/max здесь работают иначе чем quality — меньшее значение означает лучшее качество. Диапазон 20–35 даёт хороший баланс.

Онлайн-инструменты: Squoosh.app (браузерный, от Google, отличный для ручной обработки с предпросмотром), TinyPNG/TinyJPEG (работают и с WebP), ImageOptim (macOS, пакетный).

Ориентир по итоговым размерам: фото для блога — до 100 КБ, hero-изображение — до 150 КБ, иконки и UI-элементы — до 20 КБ. Если файл выходит за эти рамки при приемлемом качестве — пора снижать resolution.

Размеры: главная ошибка

Самая распространённая ошибка, которую мы видим на аудитах — загрузить изображение 2000×1500 пикселей туда, где оно отображается в блоке 400×300 px. Браузер загружает полный файл, потом масштабирует его средствами CSS. Вы везёте 800 КБ там, где нужно 80.

Атрибуты srcset и sizes решают эту проблему. Они позволяют браузеру выбрать правильную версию изображения под конкретный экран.

Базовый пример:

<img
  src="photo-800.webp"
  srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1200.webp 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 800px"
  alt="Описание изображения"
  width="800"
  height="600"
/>

Как это читается: srcset перечисляет доступные версии с их шириной в пикселях. sizes описывает, сколько места занимает изображение при разных ширинах вьюпорта. Браузер умножает: если экран 390px и изображение занимает 100% ширины — нужна версия ~390px. Он выбирает ближайшую из srcset — photo-400.webp.

Для WordPress атрибуты srcset генерируются автоматически, если медиафайлы загружать через стандартный загрузчик и настроить размеры в Settings → Media. Но исходники нужно загружать в правильном разрешении — WordPress не ухудшит качество, но и не создаст версии лучше оригинала.

Практическое правило: готовьте изображения в трёх размерах — 400px, 800px, 1200–1600px. Для полноширинных блоков добавьте 2000px для Retina-экранов.

Lazy loading

Атрибут loading="lazy" сообщает браузеру, что изображение можно загрузить тогда, когда пользователь начинает прокручивать страницу к нему, а не сразу при открытии страницы.

<img src="photo.webp" loading="lazy" alt="..." width="800" height="600" />

Поддержка браузерами — 97%+, дополнительные библиотеки не нужны. Эффект ощутим: на страницах с 10–20 изображениями в блоге lazy loading снижает начальный вес загрузки в 3–5 раз.

Важное исключение: изображения в области above-the-fold — то есть те, которые видны без прокрутки при первой загрузке — lazy loading ставить нельзя. Это ухудшает LCP, потому что браузер сначала строит страницу, потом «замечает» что нужно загрузить изображение, и только тогда загружает.

Что считать above-the-fold: первые 600–700 пикселей страницы на мобильном устройстве (примерно один экран телефона в вертикальной ориентации). Обычно это hero-изображение, логотип, и возможно первый баннер. Всё, что ниже — lazy.

Как определить точно: откройте Chrome DevTools, перейдите на вкладку Performance, запишите загрузку страницы. В отчёте увидите LCP Element — это и есть изображение, которое нельзя ленить.

fetchpriority="high" для LCP-изображения

Браузер обнаруживает изображения по-разному. Изображение в теге <img> в HTML парсится при загрузке страницы. Изображение через CSS background-image — нет. Но даже когда браузер видит <img>, он присваивает изображениям разные приоритеты загрузки в зависимости от их позиции на странице.

Атрибут fetchpriority="high" прямо говорит браузеру: «загрузи это изображение первым».

<img
  src="hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="Главный баннер"
  width="1200"
  height="600"
/>

Где ставить: только на одно изображение — то, которое является LCP-кандидатом. Обычно это главный hero-баннер на главной, первое изображение в статье блога, или ключевое фото продукта на карточке товара.

Почему нельзя ставить везде: если вы помечаете 5 изображений как high priority, браузер пытается загрузить все пять одновременно. Конкуренция за полосу пропускания нивелирует эффект. Один fetchpriority="high" на страницу — правило без исключений.

Поддержка: Chrome 101+, Safari 17.2+, Firefox 128+. На несовместимых браузерах атрибут игнорируется без ошибок.

width и height обязательно

Атрибуты width и height в теге <img> — это не про масштабирование. Это про CLS (Cumulative Layout Shift): насколько сдвигаются элементы страницы при загрузке.

Когда браузер начинает рендерить страницу, он не знает размер изображения до его загрузки. Если размеры не указаны — браузер резервирует место с высотой 0, потом изображение загружается и «раздвигает» страницу. Элементы ниже прыгают. Пользователь, читавший текст, теряет место. CLS растёт.

Когда width="800" height="600" указаны — браузер с первого рендера резервирует правильное пространство с соотношением сторон 4:3. Страница не прыгает. CLS = 0 для этого элемента.

<!-- Плохо: CLS гарантирован -->
<img src="photo.webp" alt="Фото" />

<!-- Хорошо: браузер резервирует место сразу -->
<img src="photo.webp" alt="Фото" width="800" height="600" />

Важный нюанс: CSS может растягивать или сжимать изображение как угодно — атрибуты width/height задают только соотношение сторон для резервирования. Поэтому width="4" height="3" и width="800" height="600" дадут одинаковый эффект, хотя принято писать реальный размер.

Все популярные CMS умеют автоматически вставлять width/height при загрузке медиафайлов — убедитесь, что эта функция включена и что загружаемые файлы не повреждены (для повреждённых файлов размер определить нельзя).

Alt-теги

Короко, потому что тема заслуживает отдельного разбора: alt-атрибут выполняет две функции. Первая — доступность: скринридеры читают alt тем, кто не видит изображение. Вторая — SEO: поисковики понимают содержимое изображения по тексту alt, индексируют изображения в Яндекс Картинки и Google Images, и учитывают alt при ранжировании страницы. Пустой alt — потерянный SEO-сигнал на каждом изображении.

Инструменты проверки

Google PageSpeed Insights (pagespeed.web.dev) — бесплатно, показывает конкретные изображения с рекомендациями: «использовать следующие форматы нового поколения», «правильно выбирайте размер изображений». Даёт оценку экономии в КБ.

Squoosh.app — браузерный инструмент Google для ручного сжатия с визуальным сравнением. Идеален для одиночных изображений, когда нужно точно оценить соотношение качество/размер.

TinyPNG / TinyJPEG (tinypng.com) — работают и с WebP, пакетная обработка через drag-and-drop, API для автоматизации.

ImageOptim (imageoptim.com) — macOS-приложение, пакетная обработка папок, поддерживает все форматы. Хорош для финальной «выжимки» после конвертации.

Chrome DevTools → Network tab → Images — покажет реальный вес и время загрузки каждого изображения на странице, отфильтровав только медиафайлы.

Чеклист оптимизации изображений

Конвертировать все новые изображения в WebP (качество 75–85)
Для hero- и LCP-изображений протестировать AVIF с fallback через <picture>
Подготовить три размера srcset: 400px, 800px, 1200px (плюс 2000px для full-width)
Прописать атрибуты width и height на всех <img>
Поставить loading="lazy" на все изображения ниже первого экрана
Поставить fetchpriority="high" и loading="eager" только на LCP-изображение
Заполнить alt на каждом изображении — кратко и по существу
Проверить результат в PageSpeed Insights — цель: зелёный LCP (< 2.5 сек) и CLS < 0.1

Разбираем скорость сайта в рамках технического SEO-аудита — обсудить проект.