AVIF или WebP для сайта: качество, вес и стоимость обработки

Изображения часто формируют значительную часть передаваемых страницей данных, поэтому переход с JPEG и PNG на современные форматы действительно может ускорить сайт. Однако выбирать между AVIF и WebP только по размеру готового файла неправильно. Необходимо учитывать качество изображения, время кодирования, нагрузку на процессор, число создаваемых вариантов, скорость декодирования в браузере и поддержку клиентских устройств.

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

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

Чем AVIF отличается от WebP

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

WebP основан на технологиях видеокодека VP8 и давно применяется как замена JPEG, PNG и в некоторых случаях GIF. Формат хорошо поддерживается современными браузерами, распространёнными графическими библиотеками и сервисами обработки изображений. Его сильная сторона — зрелая инфраструктура и сравнительно предсказуемая скорость преобразования.

AVIF хранит изображения на основе технологий AV1. Более современные алгоритмы позволяют кодеру эффективнее описывать сложные участки кадра. Особенно заметным преимущество может быть на фотографиях, градиентах и изображениях, где нужно сохранить приемлемое качество при низком битрейте. Цена этой эффективности — более сложное кодирование и зависимость результата от выбранного кодека, его настроек и доступных вычислительных ресурсов.

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

Качество и вес файлов

При сопоставимом визуальном качестве AVIF часто позволяет получить более компактную фотографию, чем WebP. Но фиксированного процента экономии, применимого к любому сайту, не существует. Итог зависит от содержания кадра, разрешения, уровня качества, цветовой субдискретизации, глубины цвета, версии и реализации кодера.

На результат особенно влияют следующие особенности изображения:

• мелкие текстуры: листва, волосы, ткань, песок и шерсть;
• плавные градиенты неба, теней и студийного фона;
• тонкие линии, текст и контрастные границы;
• шум, зерно и артефакты уже сжатого JPEG;
• прозрачные области и полупрозрачные тени;
• маленький физический размер изображения.

AVIF способен хорошо сохранять детали при небольшом размере файла, но на агрессивных настройках у него могут появляться размытие текстур, потеря мелких деталей и искажения вокруг контрастных объектов. У WebP при сильном сжатии также возникают размытие, блочные структуры и ореолы. Характер артефактов различается, поэтому сравнивать форматы нужно визуально, а не по одинаковому числу в параметре качества.

Значение quality у разных кодеров и форматов не является единой шкалой. WebP с качеством 75 и AVIF с качеством 75 нельзя автоматически считать равными по детализации или размеру.

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

Фотографии

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

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

Графика, логотипы и скриншоты

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

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

Прозрачность

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

Если оригинал не содержит прозрачности, добавлять альфа-канал не нужно: это усложняет представление данных и может увеличить файл.

Почему AVIF кодируется медленнее

Кодирование — поиск способа представить изображение с заданным балансом качества и размера. Чем больше вариантов анализирует кодер, тем больше процессорного времени он может потратить. AV1 предоставляет сложные инструменты сжатия, поэтому получение компактного AVIF обычно обходится дороже, чем создание сопоставимого WebP.

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

WebP тоже имеет настройки скорости и качества, однако в типичном серверном конвейере его генерация обычно проще и быстрее. Это важно, когда посетитель загружает изображения через личный кабинет, редакция публикует много материалов одновременно или магазин регулярно импортирует крупный каталог.

На время обработки влияют:

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

Фотография размером 6000 × 4000 пикселей требует обработки 24 миллионов пикселей до создания каждого варианта. Если из неё формируются шесть разрешений в двух современных форматах, один исходник запускает целую серию операций. Поэтому ограничение размеров загружаемых оригиналов и раннее уменьшение изображения заметно влияют на стоимость конвейера.

Декодирование в браузере

Сервер передаёт сжатый файл, после чего браузер должен декодировать его в пиксели. Уменьшение сетевого трафика полезно, но более сложный формат может потребовать дополнительных вычислений на устройстве посетителя. AVIF в ряде сценариев декодируется тяжелее WebP, особенно на старых или маломощных устройствах. Реальный результат зависит от браузера, процессора, аппаратных возможностей и реализации декодера.

Не следует оценивать декодирование только по размеру файла. После распаковки память определяется прежде всего разрешением. Обычное представление 8-битного изображения с четырьмя каналами требует примерно четыре байта на пиксель без учёта дополнительных буферов. Картинка размером 4000 × 3000 пикселей может занимать около 48 Мбайт в распакованном виде, даже если передаваемый AVIF весит лишь несколько сотен килобайт.

Особенно внимательно нужно тестировать:

• крупное изображение первого экрана;
• длинные страницы с десятками фотографий;
• галереи и каталоги с одновременным показом множества миниатюр;
• анимации;
• изображения высокого разрешения для экранов с повышенной плотностью пикселей.

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

Стоимость обработки на хостинге

Стоимость изображений складывается не только из дискового пространства и трафика. При серверной генерации появляются расходы процессорного времени, оперативной памяти, фоновых очередей и хранения производных файлов.

Упрощённо объём работы можно представить так:

число исходников × число размеров × число форматов = число производных файлов

Например, добавление AVIF к уже существующим WebP и JPEG увеличивает не только объём хранения. Для каждого нового или изменённого оригинала требуется дополнительное кодирование, а системе нужно отслеживать актуальность ещё одной копии.

Виртуальный хостинг

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

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

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

VPS и выделенный сервер

На VPS можно выбрать библиотеки, кодеры и схему очередей, но вместе с гибкостью появляется ответственность за ресурсы. Несколько параллельных AVIF-задач способны занять все доступные ядра и повлиять на время ответа сайта. Ограничения параллелизма здесь часто важнее максимальной скорости отдельного кодирования.

Для рабочего сервера разумно отделять обработку изображений от запросов посетителей: помещать задачи в очередь, задавать лимит одновременно работающих процессов и контролировать использование памяти. Для большого медиакаталога может быть выгоден отдельный обработчик или узел, чтобы всплеск загрузок не замедлял приложение и базу данных. Для такой схемы полезен VPS-сервер, на котором можно самостоятельно распределить ресурсы между сайтом и фоновыми задачами.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Генерировать заранее или по запросу

Предварительная генерация

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

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

Генерация по первому запросу

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

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

Гибридный подход

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

Как организовать fallback

Наиболее прозрачный способ — элемент <picture>. Браузер проверяет источники по порядку и выбирает первый поддерживаемый формат. AVIF следует указывать до WebP, а обычный JPEG или PNG оставлять в <img> как универсальный резерв.

<picture>
  <source
    type="image/avif"
    srcset="photo-640.avif 640w, photo-1280.avif 1280w"
    sizes="(max-width: 700px) 100vw, 1200px">
  <source
    type="image/webp"
    srcset="photo-640.webp 640w, photo-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 1200px">
  <img
    src="photo-1280.jpg"
    srcset="photo-640.jpg 640w, photo-1280.jpg 1280w"
    sizes="(max-width: 700px) 100vw, 1200px"
    width="1280"
    height="853"
    alt="Описание изображения">
</picture>

Атрибут type позволяет браузеру пропустить неподдерживаемый источник, не загружая его. Атрибуты srcset и sizes решают другую задачу: помогают выбрать подходящее разрешение. Формат и размер следует оптимизировать одновременно.

Указанные width и height задают соотношение сторон и помогают браузеру зарезервировать место до загрузки. Значения не запрещают адаптивное масштабирование через CSS.

Выбор формата по заголовку Accept

Сервер или CDN может отдавать разные форматы по одному URL, анализируя заголовок Accept. HTML становится компактнее, но кеширование усложняется. Кеш должен различать варианты ответа, иначе один клиент может получить файл, предназначенный для другого браузера.

Такая схема требует корректного ключа кеша, правильного MIME-типа и согласованной работы сервера, прокси и CDN. Заголовок Vary: Accept сообщает о зависимости ответа, но его влияние на эффективность кеша тоже нужно учитывать. Если инфраструктура не поддерживает преобразование и вариативное кеширование надёжно, отдельные URL внутри <picture> проще диагностировать. Подробнее о настройке вариантов WebP и AVIF через Accept, кешировании и fallback рассказывает статья о конверсии и отдаче WebP/AVIF в Nginx.

Какие изображения не стоит конвертировать автоматически

Тотальное преобразование медиатеки может увеличить расходы без заметной пользы. Отдельной проверки требуют:

• очень маленькие иконки, где служебные данные контейнера сопоставимы с полезными;
• SVG-иллюстрации и логотипы, не нуждающиеся в растрировании;
• изображения с текстом и схемами;
• файлы, которые пользователи должны скачивать в исходном формате;
• анимации с большим числом кадров;
• уже сильно сжатые оригиналы с заметными JPEG-артефактами;
• материалы, для которых критичны цветовой профиль и точность цветопередачи.

Повторное сжатие с потерями не восстанавливает качество. Если исходный JPEG уже повреждён компрессией, новый формат может лишь сделать дефекты менее или более заметными. Для будущей обработки лучше хранить качественный мастер-файл отдельно от веб-копий.

Как сравнить AVIF и WebP на собственном контенте

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

1. Подготовить одинаковые исходники без промежуточного повторного сжатия.
2. Сначала создать целевые размеры, а затем кодировать каждый размер в AVIF и WebP.
3. Подобрать несколько уровней качества для каждого формата, не приравнивая числовые значения.
4. Сравнить детали при масштабе 100%, а также реальный вид в макете на настольном и мобильном экране.
5. Зафиксировать размер файла, время кодирования и пиковое потребление памяти.
6. Проверить страницу на устройствах разной производительности и при ограниченной скорости соединения.

Объективные метрики качества могут помочь отсеять неудачные настройки, но не заменяют визуальную проверку. Метрика способна оценить отличие от оригинала, однако не всегда правильно отражает читаемость текста, восприятие лица или важность конкретной детали товара.

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

Практические стратегии выбора

Только WebP и резервный JPEG или PNG

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

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

AVIF, WebP и резервный формат

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

Недостатки — дополнительное кодирование, больший объём хранилища и усложнение очистки кеша. Такой вариант стоит внедрять, если замеры на реальном контенте подтверждают достаточную экономию.

AVIF только для крупных фотографий

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

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

Как снизить серверные расходы

• Уменьшать исходник до обработки. Не кодировать многомегапиксельную фотографию целиком, если оригинал нужен только для веб-показа меньшего размера.
• Ограничивать набор разрешений. Несколько обоснованных ступеней лучше десятков почти одинаковых вариантов.
• Генерировать асинхронно. Загрузка страницы не должна ждать медленного AVIF-кодера.
• Ограничивать параллелизм. Очередь предотвращает захват всех процессорных ядер массовым импортом.
• Хранить результат. Повторное кодирование одного и того же оригинала при каждом запросе недопустимо.
• Использовать устойчивые имена кеша. В имени или ключе полезно учитывать версию оригинала и профиль обработки.
• Удалять устаревшие варианты. После замены исходника старые производные файлы иначе продолжат занимать место.
• Не выбирать самый медленный профиль без теста. Незначительное уменьшение файла может не окупить резкий рост времени обработки.

Следует учитывать и стоимость хранения. Если оригинал имеет шесть размеров и три формата, один объект превращается в восемнадцать производных файлов. Для миллиона товаров это уже отдельная задача управления медиахранилищем, даже если каждый файл относительно мал.

Что контролировать после внедрения

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

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

Важно проверить заголовок Content-Type: сервер должен отдавать image/avif для AVIF и image/webp для WebP. Также нужно убедиться, что резервный источник действительно открывается, а кеш не смешивает разные форматы.

При изменении профилей качества не обязательно немедленно перекодировать всю медиатеку. Можно применить новые параметры к свежим загрузкам, затем обработать наиболее посещаемые материалы и только после оценки результата запускать полную миграцию. Такой порядок снижает риск длительной нагрузки и упрощает откат.

AVIF или WebP: итоговый выбор

AVIF стоит выбирать там, где критичен минимальный вес крупных фотографий, а инфраструктура позволяет выполнять более затратное кодирование в фоне. Он особенно полезен для медианасыщенных статей, галерей и каталогов, если тесты показывают реальное преимущество на типичных изображениях проекта.

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

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

Главный принцип — оптимизировать всю цепочку, а не отдельное расширение. Правильное разрешение, адаптивные варианты, проверенное качество, фоновая генерация, постоянный кеш и контролируемый fallback влияют на результат не меньше, чем выбор между AVIF и WebP.