AVIF или WebP: что меньше и когда

Что такое AVIF и WebP

WebP — формат изображений Google, представленный в 2010 году. Его режим с потерями сжимает картинку так же, как видеокодек VP8 сжимает отдельный кадр; отдельный режим без потерь, VP8L, рассчитан на графику с чёткими краями и небольшим числом цветов. Оба режима поддерживают прозрачность, а анимированный WebP может заменить GIF.

AVIF (AV1 Image File Format) хранит кадр, сжатый AV1 — свободным от отчислений видеокодеком Alliance for Open Media, — внутри контейнера HEIF. Спецификация 1.0 вышла в 2019 году. Инструменты кодирования AV1 на десятилетие новее, чем у VP8, поэтому AVIF сохраняет больше деталей на байт на фотографиях, а также добавляет 10- и 12-битный цвет и HDR. Цена — время кодирования: получить AVIF заметно дороже по CPU, чем WebP той же картинки, поэтому сервисы изображений конвертируют один раз и кешируют результат.

Поддержка браузерами больше не главный вопрос. По данным caniuse.com на 30 сентября 2026 года, WebP показывают около 97% используемых браузеров, AVIF — около 95%. WebP работает начиная с Chrome 32, Firefox 65 и Safari 14 (на macOS 11 и новее); AVIF — с Chrome 85, Firefox 93, Safari в iOS 16, Safari 16.4 на Mac (статичные изображения — с Safari 16.1 на macOS 13 Ventura и новее) и Edge 121. Оставшиеся несколько процентов — причина, по которой запасной вариант всё ещё важен, а при согласовании формата на сервере он ничего не стоит.

Что меньше? Зависит от изображения

Большинство сравнений называют одно число — «WebP меньше на 30%» или «AVIF вдвое уменьшает изображения», — усреднённое по фотографиям. Но настоящий сайт отдаёт ещё скриншоты, логотипы и иконки, и там порядок может перевернуться. 5 октября 2026 года мы прогнали четыре изображения через оптимизатор изображений CDN.com.tr с его рабочими настройками и посчитали байты, которые дал каждый формат.

Новостное фото, JPEG, 1920×1080. Оригинал 262 025 байт; оптимизированный JPEG 186 137; WebP 113 860; AVIF 86 936. Хрестоматийный случай: WebP на 39% меньше оптимизированного JPEG, а AVIF ещё на 24% меньше WebP — треть байтов оригинала.

Новостное фото, JPEG, 926×594. Оригинал 131 472 байта; оптимизированный JPEG 93 348; WebP 89 360; AVIF 77 452. Такая же картинка, только меньше и уже хорошо сжатая: по сравнению с JPEG WebP экономит лишь 4%, AVIF — 17%.

Скриншот панели, PNG, 1156×775. Оригинал 105 078 байт; оптимизированный PNG (pngquant и optipng) 40 379; WebP 41 218; AVIF 27 942. Плоские цвета и текст — сильная сторона PNG с палитрой: WebP вышел на 839 байт больше PNG, а AVIF всё равно оказался на 31% меньше него.

Фавикон, PNG, 16×16. Оригинал 701 байт; оптимизированный PNG 483; WebP 314; AVIF 682. При таком размере всё решает контейнер: 429 из 682 байт AVIF — это блоки HEIF, которые описывают изображение ещё до первого пикселя, тогда как обёртка WebP занимает 46 байт. AVIF получился на 41% больше PNG, а самым маленьким оказался WebP.

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

Как сервер выбирает формат

Каждый запрос изображения несёт заголовок Accept со списком форматов, которые браузер умеет показывать. Chrome отправляет image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8; браузер без поддержки AVIF не указывает image/avif. Сервер или CDN, конвертирующие изображения, читают этот список и отвечают на тот же URL в AVIF, WebP или оригиналом. Имя файла не меняется, так что hero.png может прийти в AVIF: что именно отправлено, говорит заголовок Content-Type, а не расширение.

Раз у одного URL теперь несколько возможных ответов, ответ должен содержать Vary: Accept. Он велит каждому кешу на пути — от CDN до корпоративного прокси и браузера — хранить отдельную копию для каждого значения Accept. Без него общий кеш может отдать AVIF, полученный одним посетителем, следующему, чей браузер не умеет его показывать.

Другой подход переносит выбор в HTML. Элемент <picture> перечисляет файлы <source> с type="image/avif" и type="image/webp", браузер берёт первый поддерживаемый тип, а <img> внутри служит запасным вариантом. Логика на сервере и Vary не нужны, но каждый вариант приходится создавать и хранить самому и держать разметку в актуальном состоянии. В обоих случаях, чтобы проверить, что браузер получает на самом деле, хватит трёх запросов.

Одно изображение, три заголовка Accept: сравните ответы

# браузер, который принимает AVIF и WebP
curl -so /dev/null -w '%{content_type} %{size_download} байт\n' \
  -H 'Accept: image/avif,image/webp,*/*' https://example.com/hero.png

# браузер, который поддерживает только WebP
curl -so /dev/null -w '%{content_type} %{size_download} байт\n' \
  -H 'Accept: image/webp,*/*' https://example.com/hero.png

# клиент, который не просит ничего конкретного
curl -so /dev/null -w '%{content_type} %{size_download} байт\n' \
  -H 'Accept: */*' https://example.com/hero.png

# заголовок, который держит общие кеши честными (GET, а не HEAD)
curl -s -D - -o /dev/null -H 'Accept: image/avif,*/*' \
  https://example.com/hero.png | grep -i '^vary'

Проверьте, что отдаёт ваш сайт

Проверка ниже выполняет эти запросы для целой страницы. Она читает HTML страницы, берёт до 20 изображений из <img>, srcset, <picture> и og:image и запрашивает каждое дважды: как современный браузер (Accept: image/avif,image/webp,…) и как клиент, принимающий что угодно (Accept: */*). По первым байтам каждого ответа она определяет настоящий формат, что бы ни говорило имя файла, считает байты и показывает Vary и статус кеша. Можно ввести и адрес отдельного изображения.

Запросы уходят с нашего сервера в Турции, поэтому CDN может отвечать нам из другого места, чем вашим посетителям. Изображения, которые JavaScript добавляет после загрузки страницы, и фоны из CSS не входят в HTML и не проверяются. Все ограничения описаны на странице самой проверки.

Как читать результаты

AVIF или WebP. Браузер, который просил современные форматы, получил один из них. Размер рядом — то, что скачал этот браузер; столбец «Другие браузеры» — то, что получает любой браузер без поддержки AVIF и WebP. Строка экономии суммирует только изображения, оба ответа по которым прочитаны целиком и пришли в разных форматах: это измерение, а не оценка.

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

Один и тот же файл для всех браузеров. Оба запроса получили один формат. Так выглядит сайт без согласования формата — и сайт, который уже отдаёт всем файлы .webp: их показывает любой современный браузер, но дополнительная экономия AVIF остаётся неиспользованной. Сравнивать нечего, поэтому экономия не показывается.

Без Vary: Accept. Ответ меняется в зависимости от Accept, но не сообщает об этом, и общие кеши могут его сохранить. Исправьте это в первую очередь: это единственный результат в списке, из-за которого посетитель может увидеть сломанное изображение.

Ограничение запросов или блокировка. Некоторые сайты отвечают на автоматические запросы кодами 429, 403, проверкой на бота или маленькой страницей 503. Тогда проверка перестаёт обращаться к этому хосту до своего конца и помечает оставшиеся изображения как непроверенные. Это говорит о защите сайта, а не о его изображениях: повторите через несколько минут или проверьте адрес одного изображения напрямую.

Разумная стратегия: сначала AVIF, потом WebP, и никогда не больше

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

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

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

AVIF и WebP на CDN.com.tr

Оптимизация изображений — это переключатель в панели, для всего аккаунта или для одного правила доставки. Когда он включён, edge отдаёт изображения JPEG и PNG в WebP браузерам, которые его поддерживают; наш сервис изображений конвертирует каждое изображение один раз, а edge кеширует результат. Для аккаунта можно также выбрать WebP + AVIF: тогда браузеры, принимающие AVIF, получают AVIF, остальные современные браузеры — WebP, а все прочие — изображение в исходном формате, всё с одного URL, с Vary: Accept и отдельной копией в кеше для каждого формата.

Обработка списывается из месячной квоты, причём AVIF — по более высокому тарифу, чем WebP, потому что требует больше CPU; панель показывает тариф рядом с переключателем. Запустите проверку выше на своих страницах, чтобы по каждому изображению увидеть, в каком формате и какого размера его получает каждый браузер.