WebP vs AVIF vs JPEG: какой формат изображений выбрать в 2026?

Коротко: AVIF на 20–30% меньше WebP и на 30–50% меньше JPEG. WebP примерно на 25–35% меньше JPEG. AVIF кодируется в 5–20 раз медленнее WebP, тогда как WebP декодируется быстрее всех трёх. Выигрышный сценарий 2026 года: первым отдавать AVIF, при невозможности откатываться на WebP, держать JPEG как универсальную страховку и дать браузеру выбрать вариант через элемент <picture>.

Этого ответа достаточно большинству читателей. Куда интереснее вопрос, когда не надо браться за AVIF. Пропустите его на жёстких бюджетах CI, где время кодирования важнее байтов. Не используйте для пользовательских загрузок в реальном времени: кодирование AVIF на стороне браузера всё ещё работает фрагментарно. Оставляйте JPEG основным, если вам нужна совместимость с iOS 16.0–16.3 или старыми сборками Edge в продакшене. В остальных случаях AVIF выигрывает по размеру файла, при условии что разметка <picture> корректна, а CDN отдаёт правильный MIME-тип.

Дальше идут рабочие детали: цифры по поддержке в 2026, бенчмарк на реальной фотографии, дерево решений по сценариям, готовые к копированию шаблоны <picture>, команды конвертации и четыре ловушки, на которых команды теряют время. Если надо просто сконвертировать файл, наше бесплатное сжатие изображений обрабатывает JPEG, PNG, WebP и AVIF прямо в браузере, ничего не загружая на сервер.

1. Поддержка браузерами в 2026: WebP 97%, AVIF 93%

Через два с половиной года после того, как Edge выпустил AVIF, разрыв в поддержке сократился до нескольких процентов глобального трафика. Вопрос уже не «поддерживается ли», а «что отдавать оставшимся 3%».

1.1 WebP: безопасный выбор по умолчанию

WebP появился в Chrome ещё в 2012 году, в Firefox 65 (2019), Edge 18 (2018) и Safari 14 (2020). По данным caniuse, на май 2026 года глобальная поддержка составляет около 97%. WebP вырос из «современной альтернативы» в «жизнеспособный fallback». Если вы отдаёте только один формат помимо JPEG, это WebP.

1.2 AVIF: уже годится в качестве основного формата

AVIF появился в Chrome 85 (август 2020) и Firefox 93 (октябрь 2021). Safari 16.4 включил его на macOS и iOS в марте 2023 года. Edge подтянулся последним и добавил поддержку декодирования только в 121-й версии (январь 2024). Глобальное покрытие на май 2026 примерно 93–95%.

Об одном остром моменте: в iOS 16.0–16.3 есть известный баг декодирования AVIF, который может уронить Safari на определённых изображениях. Эти сборки всё ещё живы на устройствах, удерживаемых корпоративным MDM, поэтому AVIF без рабочего fallback на WebP или JPEG превращается в реальный риск отказа. Относитесь к нему как к «основному формату со страховкой», а не «основному в одиночку».

1.3 Краткая таблица совместимости

Формат	Глобальная поддержка (май 2026)	Главное ограничение
JPEG	100%	Самые большие файлы; нет прозрачности; нет HDR
WebP	~97%	Нет HDR и 10-битного цвета
AVIF	~93–95%	Медленное кодирование; баг декодирования в iOS 16.0–16.3; требует Edge 121+

2. Ключевые различия: сжатие, скорость, возможности

2.1 Эффективность сжатия на реальной фотографии

Один бенчмарк на одном источнике. Пейзажная фотография 4000×3000, исходный PNG около 24 МБ, перекодирование с перцептивно сопоставимым качеством:

Кодирование	Размер	Относительно базы JPEG
JPEG q75 (mozjpeg)	~2,1 МБ	0% (база)
WebP q75 (libwebp)	~1,4 МБ	на 33% меньше
AVIF q60 (libavif, cpu-used 4)	~1,0 МБ	на 52% меньше

AVIF q60 здесь визуально эквивалентен JPEG q80 и WebP q75. Шкалы качества между кодеками невзаимозаменяемы. Перекодирование «JPEG q75 в AVIF q75» — классическая ошибка новичка: вы получаете раздутый AVIF, который выглядит идентично источнику.

2.2 Скорость кодирования: налог в 5–20 раз

AVIF сжимает сильнее, потому что выполняет больше работы. С libavif при значении по умолчанию cpu-used 4 изображение 4000×3000 кодируется в 5–20 раз дольше, чем libwebp, и примерно в 50 раз дольше, чем mozjpeg. Эта стоимость накапливается в CI-сборках, холодных стартах Lambda и пайплайнах, которые перекодируют тысячи ассетов.

Два аварийных клапана. cavif --speed 9 (или libavif cpu-used 9) приближается к libwebp с разницей в 3 раза ценой 5–8% увеличения файла. Второй — агрессивное кэширование: пайплайн ассетов с адресацией по содержимому, который пропускает перекодирование неизменённых источников, превращает медленный кодек в одноразовую трату.

2.3 Глубина цвета и HDR

JPEG и WebP заканчиваются на 8-битном sRGB. AVIF нативно работает с 10- и 12-битным цветом, Rec. 2020, DCI-P3 и передаточными функциями PQ/HLG. Для миниатюр HDR-видео, профессиональных фотогалерей и браузерных print-proof сегодня AVIF остаётся единственным стандартизированным вариантом.

2.4 Прозрачность и анимация

У JPEG нет ни того, ни другого. WebP и AVIF поддерживают и альфа-канал, и анимацию. При замене прозрачных PNG AVIF кодирует альфу компактнее: иллюстрация интерфейса, которая в WebP сжимается на 30–40%, в AVIF часто сжимается на 50–70%.

3. Дерево решений: какой формат под какую задачу

3.1 Статические сайты: блоги, маркетинговые страницы, документация

AVIF — основной, WebP — fallback, JPEG — страховка. Кодирование происходит один раз в CI, поэтому налог в 5–20 раз платится временем сборки, а не временем пользователя. Это канонический случай для шаблона <picture> с тремя источниками из раздела 4.

3.2 Пользовательские загрузки: аватары, UGC, вложения форм

Сжимать в WebP в браузере, асинхронно перекодировать в AVIF на сервере. canvas.toBlob('image/avif') в браузере сегодня работает только в Chrome 99+, поэтому AVIF не подходит для пути загрузки. WebP быстро сжимается в браузере и экономит трафик уже на самой загрузке.

Подробное сравнение клиентских библиотек (Squoosh, browser-image-compression, Compressor.js) и того, как они сочетаются с серверными Sharp или Imagemin, есть в смежном руководстве по сжатию: браузер vs Node.js. Выбор формата и место обработки — это ортогональные оси; здесь мы покрываем именно ось формата.

3.3 HDR и фотография высокой точности

Только AVIF. Больше ничто в открытом веб-стеке сегодня не поддерживает 10- или 12-битный цвет. Для HDR-only ассетов либо пропустите fallback, либо смиритесь с тем, что JPEG-fallback будет SDR.

3.4 Аудитории с тяжёлым легаси-парком браузеров

JPEG — основной, WebP — опционально, AVIF — нет. Государственные порталы, отдельные восточноазиатские корпоративные среды и B2B-инструменты с длинным хвостом устройств иногда показывают в аналитике 5–10% трафика IE и старого Edge. WebP сейчас безопасен, AVIF пока нет.

3.5 Раздача через CDN в реальном времени

Серверный libvips или Sharp с потоковой выдачей WebP, AVIF генерируется фоновым воркером и отдаётся при попадании в кэш. Не блокируйте ответ кодированием AVIF. Cloudflare Polish, Vercel Image Optimization и Cloudinary f_auto автоматизируют этот шаблон.

4. Fallback через `<picture>`: как сделать правильно

Элемент <picture> существует именно для того, чтобы браузер мог выбрать лучший поддерживаемый источник. Три слоя с AVIF на первом месте дают оптимальный байтовый бюджет, не ломая старых клиентов.

4.1 Базовый трёхслойный шаблон

<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="800"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

Три момента, на которые надо обратить внимание. Браузер обходит элементы <source> сверху вниз и выбирает первый, чей type он понимает; всё остальное игнорируется и не загружается. Тег <img> — это собственно отрисовываемый элемент, и он наследует атрибуты (alt, sizes, классы) независимо от того, какой источник выиграл. Атрибуты же width и height на <img> в 2026 году уже не являются необязательными: они резервируют место и предотвращают Cumulative Layout Shift.

Для изображений выше «линии сгиба» поменяйте loading="lazy" на loading="eager" fetchpriority="high". Ленивая загрузка LCP-изображения — один из самых распространённых самопрострелов по Core Web Vitals.

4.2 Адаптивность плюс формат: полный шаблон

Когда нужны ещё и адаптивные разрешения, повторите srcset внутри каждого <source>:

<picture>
  <source type="image/avif"
          srcset="/img/hero-800.avif 800w,
                  /img/hero-1600.avif 1600w,
                  /img/hero-2400.avif 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <source type="image/webp"
          srcset="/img/hero-800.webp 800w,
                  /img/hero-1600.webp 1600w,
                  /img/hero-2400.webp 2400w"
          sizes="(min-width: 1024px) 1600px, 100vw" />
  <img src="/img/hero-1600.jpg"
       width="1600" height="900"
       alt="Mountain landscape at sunset"
       loading="lazy" decoding="async" />
</picture>

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

4.3 Серверное согласование через `Accept` как альтернатива

Если ваш CDN это поддерживает, content negotiation сворачивает разметку до одного тега <img>. Браузер отправляет Accept: image/avif,image/webp,image/apng,*/*, а CDN отвечает лучшим поддерживаемым форматом по тому же URL.

Cloudflare Polish, Vercel Image Optimization, Cloudinary f_auto и CloudFront с Lambda@Edge реализуют этот подход. Компромисс: меньше HTML и один URL на изображение, но привязка к CDN и более тяжёлая локальная отладка. Разумный гибрид — CDN-согласование для маркетинговых страниц и явный <picture> для UI продукта, где детерминированное поведение важнее.

5. Как конвертировать изображения между форматами

5.1 В браузере, без загрузки

Самый быстрый путь для разовой задачи или небольшого пакета — только в браузере. Перетащите JPEG в бесплатное сжатие изображений, выберите WebP или AVIF на выходе, и файл не покинет вашу машину. Ввод AVIF поддерживается везде; вывод AVIF использует нативное браузерное кодирование на Chrome 85+ и прозрачно откатывается на WebP в браузерах, которые ещё не умеют кодировать AVIF.

5.2 Командная строка для пайплайнов сборки

Для продакшен-пайплайна нужен детерминированный вывод и воспроизводимые сборки. Три команды ниже — рабочие:

# AVIF: cavif (Rust, ставится через cargo или brew)
cavif --quality 60 --speed 4 input.jpg -o output.avif

# WebP: cwebp (официальный Google libwebp)
cwebp -q 75 -m 6 input.jpg -o output.webp

# Оба формата плюс ресайз, через libvips (быстрее всего на пакетах)
vips webpsave input.jpg output.webp[Q=75,effort=6]
vips heifsave input.jpg output.avif[Q=60,compression=av1,effort=4]

cavif --speed принимает значения от 0 (самое медленное, самое маленькое) до 10 (самое быстрое, самое большое). Значение 4 по умолчанию — золотая середина для ночных сборок; поднимайте до 9 для PR-превью, где скорость важнее байтов.

5.3 Интеграция со сборочным пайплайном

Большинство фреймворков для статических сайтов уже оборачивают эти кодеры. Выбирайте тот, что подходит вашему стеку:

// Next.js — next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 828, 1080, 1200, 1920, 2400],
  },
};

// Astro — astro.config.mjs
import { defineConfig } from 'astro/config';
export default defineConfig({
  image: {
    service: { entrypoint: 'astro/assets/services/sharp' },
  },
});

// Программно — Sharp (Node.js)
import sharp from 'sharp';

await sharp('input.jpg')
  .resize({ width: 1600 })
  .avif({ quality: 60, effort: 4 })
  .toFile('output.avif');

await sharp('input.jpg')
  .resize({ width: 1600 })
  .webp({ quality: 75, effort: 6 })
  .toFile('output.webp');

Для крошечных ассетов (иконки меньше примерно 5 КБ, инлайновые аватары, шапки писем) пропустите сеть совсем и встройте всё как data URI с помощью кодирования Base64. Это меняет HTTP-запрос на несколько лишних байтов HTML и обычно выигрывает на размерах ниже ~5 КБ.

Если вы выбираете между клиентскими и серверными библиотеками сжатия (Sharp, Squoosh, browser-image-compression), руководство по сжатию: браузер vs Node.js подробнее разбирает бенчмарки и компромиссы.

6. Подводные камни и заблуждения

6.1 «AVIF всегда выигрывает»: не на скриншотах и пиксель-арте

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

6.2 «Lossless WebP идеально заменяет прозрачный PNG»: почти, но не идентично

Lossless WebP действительно меньше PNG, обычно примерно на 26%. Подвох: «без потерь» относится к сжатому изображению, но кодер всё равно может изменять округление альфа-канала в областях с высоким градиентом. Для попиксельно точного воспроизведения (медицинские изображения, архивные ассеты, всё, что юридически обязано совпадать с источником) оставляйте PNG. В остальных случаях lossless WebP — чистый выигрыш.

6.3 «Просто загрузите .avif-файлы»: ваш CDN может не знать, что это такое

Старые конфиги nginx и Apache появились раньше AVIF. Если в /etc/nginx/mime.types нет строки image/avif avif;, nginx отдаёт AVIF как application/octet-stream. Браузер видит неправильный Content-Type, отказывается рендерить изображение и тихо откатывается на JPEG, сводя на нет всю оптимизацию. После деплоя сделайте curl на URL ассета и проверьте заголовок Content-Type. Пять секунд паранойи экономят неделю «почему AVIF сломан в продакшене».

6.4 Краш AVIF в iOS 16.0–16.3

Некоторые AVIF-файлы вызывают краш декодирования Safari в iOS 16.0–16.3. Баг исправлен в 16.4 (март 2023), но корпоративные MDM и медленные обновления OEM поддерживают жизнь старых устройств. Митигация: никогда не отдавайте AVIF без рабочего WebP-источника в том же <picture> и никогда не ставьте AVIF напрямую в src тега <img>. Следование шаблонам из раздела 4 уже защищает вас.

7. Шпаргалка на 2026

Сценарий	Основной	Fallback	Кодер
Статические маркетинговые страницы	AVIF q60	WebP q75 + JPEG q80	cavif + cwebp в CI
Посты блога и документация	WebP q75	JPEG q80	бесплатное сжатие изображений (вручную) или Sharp (сборка)
Пользовательские загрузки	WebP (на клиенте)	JPEG (браузер без поддержки кодирования WebP)	browser-image-compression + серверный Sharp для AVIF
HDR / профессиональная фотография	AVIF 10-bit q70	(нет — отказаться от SDR-fallback или вообще не использовать AVIF)	cavif + libavif в режиме HEIF
Раздача через CDN в реальном времени	По согласованию (AVIF или WebP)	JPEG	Cloudflare Polish, Cloudinary `f_auto`, Vercel Image

Два напоминания перед выкаткой. Всегда задавайте width и height на <img>, чтобы предотвратить CLS. Всегда проверяйте продовый заголовок Content-Type хотя бы на одном AVIF-ответе: сломанный MIME-конфиг тихо убивает AVIF в продакшене чаще любой другой неудачи из этого списка.

FAQ

Нужен ли в 2026 году JPEG-fallback?

Да. AVIF охватывает примерно 93% мировых пользователей, WebP — около 97%. Остаётся небольшая, но реальная аудитория, которой нужен JPEG: старый Edge, Firefox ниже 93, iOS до 16.4, плюс зона бага iOS 16.0–16.3. Отказывайтесь от JPEG только если аналитика показывает фактически нулевой трафик из этих браузеров и вы можете это доказать.

Как удержать сборки CI быстрыми, если кодирование AVIF медленное?

Три рычага. Используйте cavif --speed 6 или выше (по умолчанию 4), меняя ~5% размера на ~3-кратное ускорение. Параллельте по ядрам через GNU parallel или пул воркеров вашего сборщика. И кэшируйте по хэшу содержимого, чтобы неизменённые исходники полностью пропускали кодер. В сумме это обычно опускает время сборки AVIF ниже старой однопоточной базовой линии WebP.

WebP действительно декодируется быстрее AVIF?

Да. libwebp декодирует примерно в 2–3 раза быстрее libavif, и разрыв увеличивается на бюджетных мобильных. Если ваше узкое место по производительности — это декодирование (например, длинная фотогалерея на бюджетном Android-телефоне), а не сеть, WebP лучше в роли основного формата. Для большинства веб-трафика доминирует экономия на сети, и AVIF всё равно выигрывает в общем зачёте.

Видят ли AVIF пользователи iPhone?

iPhone на iOS 16.4 (март 2023) и новее поддерживают AVIF в Safari нативно. На устройствах с iOS 16.0–16.3 есть задокументированный баг декодирования, который может уронить Safari на отдельных AVIF-файлах; более старые версии iOS не поддерживают AVIF вообще. Всегда отдавайте WebP- или JPEG-fallback внутри <picture>, чтобы затронутые пользователи увидели хоть что-то.

Использовать `<picture>` или согласование через заголовок Accept?

Меньшим проектам выгоднее явная разметка <picture>: поведение детерминированно, можно отлаживать локально, а добавляется примерно 80 байт HTML на изображение. Высоконагруженные сайты выигрывают от согласования через Accept на стороне CDN: один URL на изображение, автоматические апгрейды форматов, и CDN кэширует каждый формат отдельно. Распространённый гибрид: <picture> для интерфейса приложения и CDN-согласование для маркетинговых ассетов.

Почему мой PNG стал больше после конвертации в WebP?

Почти всегда потому, что исходный PNG уже был агрессивно оптимизирован pngquant, oxipng или ZopfliPNG, и браузерный кодер на Canvas не может тягаться с этими инструментами. Перекодируйте из оригинала (экспорт Photoshop, мастер-файл из дизайн-инструмента, RAW), а не из оптимизированного PNG. Если оптимизированный PNG — ваш единственный источник, оригинал уже близок к оптимальному; оставьте его в покое.

Поддерживает ли AVIF прозрачность?

Да. AVIF поддерживает полноценный 8–12-битный альфа-канал, и его кодирование альфы в целом компактнее, чем у WebP. Прозрачная PNG-иллюстрация при конвертации в AVIF обычно сжимается на 50–70% против 30–40% в WebP. AVIF остаётся самой сильной заменой прозрачного PNG в любом контексте, который не требует попиксельно точного вывода без потерь.

Могут ли браузеры кодировать AVIF нативно через toBlob(‘image/avif’)?

Сейчас только Chrome 99+. Safari и Firefox умеют декодировать AVIF, но не умеют кодировать его через Canvas API на май 2026. Для клиентского кодирования AVIF сегодня нужны WebAssembly-библиотеки вроде libavif-wasm или jsquash, добавляющие 1–2 МБ полезной нагрузки. Большинство продакшен-стеков сжимают в WebP в браузере, а генерацию AVIF передают серверному воркеру.