Оптимизация изображений в 2026: AVIF, WebP и ленивая загрузка

Изображения остаются самыми тяжелыми ресурсами на большинстве веб-страниц. В наших проектах в DigiForze мы регулярно видим, что изображения составляют значительную часть общего веса страницы. К 2026 году ландшафт устоялся: AVIF и WebP — два современных формата, к которым стоит стремиться, адаптивные изображения через srcset стали стандартом, а ленивая загрузка настолько распространена, что неправильная реализация может навредить производительности. Эта статья обобщает наш практический опыт в четкий, авторитетный рабочий процесс, который можно применить к любому проекту.

Выбор правильного формата: AVIF против WebP

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

• AVIF обычно обеспечивает меньший размер файла, чем WebP, при том же воспринимаемом качестве. Он поддерживает 10-битный цвет, HDR, альфа-канал без потерь и даже анимацию. Кодирование значительно медленнее, чем у WebP, что делает его менее подходящим для генерации в реальном времени, но приемлемым для статических ресурсов, подготавливаемых на этапе сборки.
• WebP поддерживается всеми современными браузерами. Он предлагает предсказуемое качество, быстрое кодирование и отличные инструменты (cwebp, sharp, imagemin). Для сайтов с большим количеством контента, где важна скорость кодирования, WebP по-прежнему является прагматичным выбором по умолчанию.
• JPEG XL (JXL) подавал надежды, но так и не получил поддержки браузеров. Chromium удалил его флаг, а Safari так и не внедрил его. Не тратьте время на этот формат, пока ситуация не изменится.

Наша рекомендация: Используйте AVIF с запасным вариантом WebP. Применяйте <picture>, чтобы браузеры сначала выбирали AVIF, затем WebP, а затем исходный JPEG/PNG. Это максимизирует сжатие для тех, кто может его использовать, и никогда не оставляет пользователей без изображения. Большинство современных браузеров поддерживают AVIF, поэтому запасной вариант важен, но не является основным путем.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

Адаптивные размеры: не только srcset

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

Для простых адаптивных изображений, которые масштабируются вместе с окном просмотра, пишите:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

Но есть нюанс. sizes должен отражать фактическую ширину CSS, которую занимает изображение на каждой контрольной точке, а не долю области просмотра. Для изображения-героя, которое всегда растянуто на всю ширину, достаточно sizes="100vw". Для галереи, где каждое изображение занимает одну треть строки, используйте 33vw. Если у изображения есть отступы или оно находится внутри контейнера с максимальной шириной, необходимо вычислить фактическую отображаемую ширину — иногда для этого требуется использовать calc() в sizes.

Дескрипторы ширины против плотности пикселей

Используйте дескрипторы w (например, 400w) и sizes для гибких изображений, размер которых меняется в зависимости от макета. Дескрипторы плотности (1x, 2x) подходят только для изображений фиксированного размера, таких как логотипы или иконки, где известны точные физические размеры. Для контентных изображений всегда используйте w — это дает браузеру настоящую гибкость для выбора наилучшего кандидата на основе ширины области просмотра и коэффициента пиксельной плотности устройства.

При использовании <picture> для выбора формата каждый <source> должен иметь свой собственный srcset и опциональный sizes. Можно использовать одинаковые sources для всех источников, если макет идентичен, но не стоит дублировать их без необходимости.

Ленивая загрузка: нативная, Intersection Observer или оба подхода?

Нативная ленивая загрузка (loading="lazy") поддерживается всеми основными браузерами с 2020 года. Это решение без JavaScript, работает с изображениями и iframe и является самым простым путём. Но у него есть особенности, важные на практике:

• Нативная ленивая загрузка откладывает загрузку до тех пор, пока браузер не посчитает элемент близким к области просмотра. Порог определяется браузером – Chrome использует щедрый отступ для ранней загрузки; Firefox использует меньший отступ. Это означает, что изображения могут загружаться позже ожидаемого в Firefox.
• Она не идеально работает с srcset в некоторых ранних реализациях. Старые версии Safari (до 16.4) имели ошибки. В 2026 году это редкость, но всё же стоит тестировать.
• Для элементов <picture> атрибут loading="lazy" должен быть на теге <img>, а не на тегах <source>.

Мы используем гибридный подход: нативная ленивая загрузка как основа, плюс лёгкий полифилл на Intersection Observer (IO) для старых браузеров (хотя к 2026 году это нишевый случай). IO также может запускать анимацию появления или загружать плейсхолдеры низкого качества. Наша реализация:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

Собираем всё вместе: практический рабочий процесс

В DigiForge мы следуем этому конвейеру для каждого проекта, будь то статический сайт, сайт на CMS или веб-приложение:

1. Исходные изображения: Дизайнеры предоставляют в высоком разрешении PNG или TIFF. Мы храним оригиналы в папке _originals для будущего пережатия, если появятся новые форматы.
2. Генерация форматов: Используем Node.js-скрипт с sharp или Makefile с ImageMagick для создания AVIF, WebP и запасных JPEG/PNG в 3–5 ширинах (например, 480, 800, 1200, 1920). Для крупных проектов запускаем это параллельно с помощью рабочих потоков, чтобы ускорить сборку.
3. Настройка качества: Запускаем CI-проверки, сравнивающие размер файла с перцептивной метрикой (SSIM или Butteraugli). Мы блокируем pull request, если общий вес изображений для типовой страницы превышает разумный порог в зависимости от типа контента.
4. Разметка: Генерируем <picture> с порядком type (AVIF, WebP, запасной) и <img> с loading="lazy" (кроме первого героя). Для адаптивных размеров генерируем sizes на основе реального CSS — это часто берётся из файла токенов дизайна, общего для дизайна и разработки.
5. Раздача через CDN: Для статических сайтов раздаём предварительно закодированные ресурсы через CDN с длинными заголовками кэша (например, Cache-Control: public, max-age=31536000, immutable). Если используется CDN для изображений, например Cloudinary или imgix, многие шаги автоматизируются через URL-трансформации, но мы всё равно предварительно кодируем критичные изображения, чтобы избежать затрат на холодный старт.

Такие сайты, как Unsplash [3] и Pixabay [1], предоставляют изображения высокого разрешения, которые часто весят несколько мегабайт в сыром виде. Наш конвейер значительно уменьшает их без заметных потерь. Аналогично, AI-сгенерированные изображения из инструментов, таких как ChatGPT Images [4], часто получаются с высоким разрешением без оптимизации, поэтому прогон их через тот же рабочий процесс сжатия крайне важен. Стоковые изображения с Shutterstock [5] или Bing Images [2] имеют схожие характеристики — большие файлы, которые могут ухудшить производительность, если их не оптимизировать.

Типичные ошибки, которые мы видим (и исправляем)

• Полное отсутствие sizes: Браузер загружает самый большой кандидат из srcset, предполагая 100vw. Всегда указывайте sizes — даже простой 100vw лучше, чем ничего.
• Использование JPEG для всего: Многие команды до сих пор используют только JPEG. К 2026 году нет оправданий — WebP и AVIF зрелые, а усилия по их добавлению минимальны.
• Чрезмерная ленивая загрузка: Каждое изображение с loading="lazy" задерживает первую отрисовку контента. Используйте loading="eager" для критических изображений и рассмотрите предзагрузку hero-изображения с помощью <link rel="preload" as="image" href="..."> для максимальной скорости LCP.
• Отсутствие запасного варианта для анимированных форматов: Если вы используете анимированный AVIF (поддержка которого не везде), предоставьте запасной вариант в WebP или GIF через <picture>.
• Кодирование изображений на лету в serverless-функциях: Кодирование AVIF требует много ресурсов CPU. Всплеск запросов может привести к тайм-аутам или росту затрат. Всегда предварительно генерируйте ресурсы во время сборки, за исключением изображений, загруженных пользователями, которые невозможно подготовить заранее.

Мы также видели команды, которые полагаются на один источник изображения без версионирования. Когда дизайнер обновляет hero-баннер, старый файл перезаписывается, нарушая кеш CDN. Используйте хеши содержимого в именах файлов (например, hero-a1b2c3.avif), чтобы новые версии получали новый URL, а старые могли кешироваться бесконечно.

Рекомендации по инструментам

Для разработчиков, предпочитающих CLI, cwebp (из libwebp) и avifenc (из libavif) являются надежными и легко автоматизируемыми. Для конвейеров Node.js sharp непревзойден — он быстр, работает со всеми форматами и может выводить AVIF (требуется libvips, собранная с поддержкой AVIF). Для разовых сравнений мы используем Squoosh или инструменты сравнения, такие как icdif (Image Compare Diff).

Для крупных проектов рассмотрите использование CDN для изображений, таких как Cloudinary, imgix или Image Optimizer от Fastly. Они автоматизируют изменение размера и согласование формата через параметры URL, а также часто обрабатывают кодирование AVIF на собственном кэширующем слое, избавляя ваш сервер от нагрузки на процессор. Однако учитывайте риск привязки к вендору и стоимость – для сайта с большим количеством изображений ежемесячный счет может быть значительным. Мы часто рекомендуем гибридный подход: предварительно генерировать наиболее распространенные размеры и форматы, а CDN поручать обработку редких контрольных точек или пользовательских загрузок.

Если вы используете CMS или генератор статических сайтов, существуют плагины для большинства фреймворков (например, @next/image для Next.js, gatsby-plugin-sharp для Gatsby, eleventy-img для Eleventy). Они автоматически выполняют генерацию и разметку, но мы рекомендуем проверять их настройки качества по умолчанию – они часто консервативны (без потерь или почти без потерь), чтобы избежать жалоб, что может приводить к избыточному расходу трафика.

Суть

Оптимизация изображений в 2026 году – это компромиссы: AVIF экономит больше всего байтов, но требует ресурсов процессора; WebP – надежный золотой стандарт. Адаптивные размеры должны быть точными, а не приблизительными. Ленивая загрузка почти автоматизирована, но требует продуманного применения, чтобы не навредить LCP. Хорошо настроенный конвейер обработки изображений может значительно уменьшить вес страницы – это прямой выигрыш для пользовательского опыта, Core Web Vitals и конверсии.

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