Оптимизация изображений

Форматы: что использовать сегодня

Цепочка запасных вариантов строится через <picture>: браузер берёт первый формат, который умеет показать.

<picture>
  <source srcset="/img/hero.avif" type="image/avif">
  <source srcset="/img/hero.webp" type="image/webp">
  <img src="/img/hero.jpg" width="1200" height="675"
       alt="Схема работы поискового робота" fetchpriority="high">
</picture>

Адаптивные изображения: srcset и sizes

Отдавать смартфону картинку шириной 2000 px — самая частая причина плохого мобильного LCP. Браузер сам выберет подходящий файл, если дать ему выбор.

<img src="/img/photo-800.webp"
     srcset="/img/photo-400.webp   400w,
             /img/photo-800.webp   800w,
             /img/photo-1600.webp 1600w"
     sizes="(max-width: 768px) 100vw, 800px"
     width="800" height="450"
     alt="Интерфейс отчёта Core Web Vitals"
     loading="lazy" decoding="async">

• srcset с дескриптором w — список доступных ширин файлов.
• sizes — какую ширину займёт картинка в макете. Без него браузер считает, что она во всю ширину экрана, и берёт файл крупнее нужного.
• width и height — всегда, это защита от CLS.
• decoding="async" — декодирование не блокирует отрисовку.

Приоритеты загрузки и LCP

LCP чаще всего измеряется по главной картинке первого экрана. Значит, у неё задача противоположная остальным: загрузиться как можно раньше.

<!-- в <head>, для картинки-героя -->
<link rel="preload" as="image"
      href="/img/hero-800.avif"
      imagesrcset="/img/hero-400.avif 400w, /img/hero-800.avif 800w"
      imagesizes="(max-width: 768px) 100vw, 800px">

Изображения, которые рисует JavaScript

Самописные скрипты ленивой загрузки (подмена data-src на src по скроллу) — источник двух проблем сразу: робот может не увидеть изображение, а пользователь получает лишнюю задержку. Нативный loading="lazy" поддерживается везде и работает лучше. Свои решения оставляйте только для галерей со сложной логикой.

Атрибут alt

• Описывайте, что изображено, обычной фразой: «Отчёт Core Web Vitals в Search Console», а не «seo продвижение сайта заказать».
• Для декоративных изображений — пустой alt="", чтобы скринридер их пропустил.
• Для изображений-ссылок alt описывает назначение ссылки, а не картинку.
• Подпись <figcaption> видна пользователю и работает лучше, чем длинный alt.

Подробнее о роли картинок в ранжировании — в уроке «Изображения как фактор ранжирования».

Практический процесс

1. Определите реальные размеры под каждый контейнер макета — обычно хватает трёх ширин.
2. Генерируйте варианты на сборке или на лету. Хорошо работает связка «оригинал в хранилище → обработчик по URL → кеш CDN».
3. Сжимайте с проверкой глазами. Для AVIF качество около 50–60 обычно неотличимо от оригинала; для WebP — 75–80.
4. Не масштабируйте вверх. Файл шире оригинала — только вес.
5. Отдавайте с длинным кешем и версией в имени файла: Cache-Control: public, max-age=31536000, immutable.
6. Проверьте LCP после изменений — в полевых данных, а не только в Lighthouse.

# подготовка вариантов, ImageMagick + avifenc/cwebp
magick photo.jpg -resize 400x  photo-400.jpg
magick photo.jpg -resize 800x  photo-800.jpg
magick photo.jpg -resize 1600x photo-1600.jpg

for f in photo-*.jpg; do
  cwebp  -q 78 "$f" -o "${f%.jpg}.webp"
  avifenc --min 24 --max 32 "$f" "${f%.jpg}.avif"
done

Итог

Картинки оптимизируются не «сжатием», а связкой решений: правильный формат, несколько размеров под разные экраны, заданные габариты и осознанные приоритеты загрузки. Следующий урок главы — современные протоколы передачи.