Форматы WebP и AVIF экономят до половины веса картинок и ускоряют загрузку страниц

Картинки забирают у средней страницы почти половину передаваемого веса, и главный виновник потерь до сих пор работает по спецификации из девяностых. Формат JPEG появился в 1992 году, сами фотографии с тех пор не изменились, а вот алгоритмы сжатия ушли далеко вперёд. Его наследники, WebP и AVIF, на одинаковых снимках экономят от четверти до половины исходного размера. Раньше переход тормозила совместимость: Safari годами не замечал новые форматы, и владелец сайта рисковал показать посетителю пустой прямоугольник вместо фотографии. К 2026 году вопрос закрыт, WebP понимает практически любой браузер, AVIF поддерживают все основные движки, а тег picture страхует редкие исключения без единой строчки скриптов. Ниже – разбор экономии на конкретных файлах, поддержки браузеров и рабочей разметки без лишней теории.

Сколько килобайт WebP и AVIF отыгрывают у JPEG на реальных файлах

Абстрактные проценты мало что говорят разработчику, поэтому цифры полезно пересчитать в килобайты на трёх типичных файлах. Баннер 1920×1080 пикселей в JPEG весит 420 КБ, конвертация в WebP с качеством 80 сжимает его до 290 КБ, экономия 31 %. AVIF с качеством 75 уменьшает тот же баннер до 205 КБ, экономия уже 51 %. Фото товара 900×600 занимает 140 КБ в JPEG, WebP снижает вес до 95 КБ, AVIF до 68 КБ, ровно половина исходного размера. Скриншот интерфейса 1200×800 падает с 310 КБ до 210 КБ в WebP и до 160 КБ в AVIF.

Разница объясняется устройством самих алгоритмов. JPEG режет кадр на квадраты 8 на 8 пикселей и кодирует каждый по отдельности, из-за чего на гладких градиентах появляются ступеньки, а вокруг контуров цветные ореолы. WebP построен на внутрикадровом кодировании видеокодека VP8 и предсказывает содержимое блока по соседним, поэтому однотонные участки почти ничего не стоят. AVIF использует наработки кодека AV1 с более крупными блоками и более точным предсказанием, отсюда и результат около половины веса при том же визуальном качестве. Замеры по метрике SSIM, которая оценивает похожесть сжатой картинки на оригинал, дают WebP минус 25–35 %, AVIF минус 45–55 %.

Практический смысл для владельца сайта простой: страница с десятью фотографиями общим объёмом 3,4 МБ после конвертации в AVIF весит около 1,7 МБ без потери качества на глаз. Пересчёт на весь каталог выглядит ещё убедительнее: 200 карточек с пятью фото на каждой отдают посетителю около 140 МБ картинок в JPEG и около 68 МБ в AVIF.

Поддержка браузеров в 2026 году закрывает вопрос совместимости

WebP к этому моменту можно считать повсеместным. Chrome понимает его с 32 версии, вышедшей в 2014 году, Firefox с 65 версии 2019 года, Safari с 14 версии, которая приехала в 2020 году вместе с обновлениями macOS Big Sur и iOS 14. Edge, Opera, Samsung Internet и мобильные браузеры поддерживали WebP давно. Суммарная доля браузеров с поддержкой держится около 97–98 %, это фактически все посетители обычного сайта.

С AVIF история свежее, но закончилась хорошо. Chrome получил поддержку в 85 версии в августе 2020 года, следом Edge и Opera на том же движке. Firefox подключил AVIF в 93 версии в октябре 2021 года. Последним сдался Safari: поддержка появилась в версии 16.4 в марте 2023 года, причём одновременно на компьютерах и на iPhone, поскольку все браузеры на iOS работают на его движке. Итоговая поддержка AVIF к 2026 году оценивается примерно в 93–95 % пользователей.

Оставшиеся проценты складываются из понятных групп: Safari 15 и старше на системах без обновлений, старые сборки Firefox, встроенные браузеры внутри приложений и почтовые клиенты. Корректно свёрстанный сайт не теряет и их, потому что тег picture держит для всех запасной вариант в JPEG. Точную долю для конкретного проекта видно в собственной статистике по моделям устройств, и если там нет раритетов, AVIF можно отдавать смело.

У форматов разная биография. WebP представили в 2010 году как графическую надстройку над видеокодеком VP8, и большую часть пути он потратил на борьбу с недоверием и ожидание Safari. AVIF появился в 2019 году как фотографический профиль кодека AV1 и был принят индустрией быстрее: крупные площадки внедрили его ещё до полной поддержки браузеров. Отдельная судьба у JPEG XL: его успели включить в Chromium, но в версии 110 в начале 2023 года поддержку убрали, и третьим форматом он не стал.

Тег picture отдаёт браузеру самый лёгкий поддерживаемый формат

Разметка, покрывающая все три формата сразу, занимает несколько строк:

<picture>
  <source srcset="/hero.avif"
    type="image/avif">
  <source srcset="/hero.webp"
    type="image/webp">
  <img
    src="/hero.jpg"
    alt="Главный баннер со сборкой компьютерного стола"
    width="1920"
    height="1080"
    fetchpriority="high">
</picture>

Логика читается сверху вниз. Браузер перебирает элементы source, проверяет тип в атрибуте type и берёт первый формат, который умеет декодировать. Chrome и Firefox остановятся на AVIF, Safari 14 возьмёт WebP, совсем старый браузер проигнорирует оба источника и покажет img с JPEG. Отсюда главное правило: источники идут от самого эффективного формата к самому совместимому, AVIF всегда выше WebP. Если порядок перепутать, современные браузеры заберут WebP и никогда не узнают про вдвое более лёгкий AVIF, а смысл половины работы исчезнет.

Атрибут type сообщает MIME-тип до загрузки, поэтому браузер не тратит трафик на файл, который не сможет открыть. Запасной img обязателен, без него вся конструкция не работает: в него выносятся alt, width, height и все стили. Пара width и height резервирует место и уберегает макет от прыжков, а fetchpriority="high" на баннере над первым экраном ускоряет доставку самой крупной картинки страницы.

Для адаптивных макетов тот же механизм работает с несколькими размерами:

<source
  type="image/avif" srcset="/card.avif 480w, /card-2x.avif 960w"
  sizes="(max-width: 520px) 92vw, 480px">

Браузер сам выберет файл подходящей ширины и не будет качать ретина-версию на обычный телефон. У picture есть и вторая работа, не связанная с форматами: через атрибут media источник привязывают к ширине экрана и отдают мобильным вертикальный кроп баннера, а десктопу горизонтальный.

Отдельная ловушка касается предварительной загрузки. Подсказка <link rel="preload" as="image"> выбирает один конкретный файл и не участвует в переборе source, поэтому с picture она либо бесполезна, либо вредна. Для баннера над первым экраном правильнее fetchpriority="high" прямо на img. Картинкам ниже первого экрана добавляют loading="lazy" и decoding="async", чтобы они не конкурировали с главным кадром за канал.

Уровень качества от 75 до 80 держит баланс между весом и детализацией

Практика выработала простую вилку: для фотографий на сайте качество 75–80 в WebP и сопоставимые настройки в AVIF дают картинку, которую не отличить от исходного JPEG, при весе в полтора-два раза меньше. Качество выше быстро съедает выигрыш, ниже появляются артефакты.

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

Границу подбирают экспериментом: одну и ту же фотографию конвертируют на нескольких уровнях качества, например 70, 75, 80 и 85, открывают кропы в масштабе 100 % и сравнивают с оригиналом. Разница между 80 и 85 видна только под лупой, зато файл на 20–30 % тяжелее. Для превью товаров, где детализация вторична, часто хватает и 70. Отдельный плюс обоих новых форматов – прозрачность без обходного PNG. lossless-режим WebP сжимает графику с текстом и скриншоты примерно на четверть лучше PNG, оба формата умеют анимацию, а animated AVIF весит в разы меньше GIF при том же качестве, так что декоративные анимации переезжают вместе с фотографиями.

Инструменты конвертации от консольных утилит до плагинов сборки

Для разовых задач хватает консоли. Утилита cwebp из пакета libwebp кодирует одной командой:

cwebp -q 80 photo.jpg -o photo.webp

AVIF собирает утилита avifenc из пакета libavif:

avifenc --min 0 --max 63 -s 6 -j 8 photo.jpg photo.avif

Параметры --min и --max задают границы квантования: чем выше верхняя граница, тем сильнее сжатие и мягче детали, ориентир для фотографий лежит в районе 40–55. Ключ -s управляет скоростью, максимальное сжатие увеличивает время кодирования в разы, поэтому сотню файлов часто кодируют на среднем уровне и лишь баннеры на медленном. ImageMagick умеет оба формата:

magick photo.jpg -quality 80 photo.webp
magick photo.jpg photo.avif

В проектах с автоматической сборкой ручная работа не нужна. Пакет sharp для Node.js перекодирует картинку парой строк, а плагины вроде gulp-webp, image-minimizer-webpack-plugin и vite-imagetools выкладывают готовые AVIF и WebP рядом с исходниками при каждой сборке. Очередная фотография, брошенная дизайнером в папку, автоматически получает все три варианта.

Существует и серверный путь без изменения разметки: модуль на сервере или CDN читает заголовок Accept и, если браузер заявляет image/avif, отдаёт по тому же адресу AVIF вместо JPEG. При таком подходе обязателен ответ с полем Vary: Accept, иначе кэш подсунет одному посетителю формат, подготовленный для другого.

Когда JPEG остаётся оправданным выбором даже в 2026 году

Мест, где старый формат всё ещё уместен, немного, но они реальные. Почтовые рассылки держат на JPEG и PNG, потому что настольный Outlook и ряд других клиентов не показывают ни WebP, ни AVIF. Пользователи Safari 15 на старых версиях macOS составляют меньше процента, но для магазина и это деньги. Крошечные картинки до 10–20 КБ не дают осмысленной экономии, возня с тремя копиями того не стоит, а иконки логичнее держать в SVG. Конвейер с частой перекодировкой тоже повод подумать: JPEG кодируется десятками миллисекунд, AVIF на максимальном сжатии занимает секунды на файл, и сотня картинок заметно удлиняет сборку.

Наконец, сам запасной вариант в img. Пока JPEG лежит в fallback, сайт получает максимум от новых форматов и не теряет ни одного старого посетителя. Исходники фотографий тем более хранят в максимальном качестве, а тройку форматов для сайта готовят уже из производных копий.

Пример миграции каталога и улучшение метрики LCP

Типовая картина перед миграцией: страница каталога с баннером и 24 фотографиями товаров, суммарно 3,8 МБ картинок в JPEG. Метрика LCP, то есть время до отрисовки самого крупного элемента экрана, на мобильных держалась около 3,4 с при нормативе 2,5 с, и проверка Core Web Vitals проходила лишь на 58 % визитов.

Работа занимает один вечер. Все фото конвертируют в AVIF с качеством 75 и в WebP с качеством 80, баннер помечают fetchpriority="high", в шаблон карточки добавляют picture с порядком source от AVIF к WebP. Суммарный вес картинок для владельцев современных браузеров падает с 3,8 до 1,9 МБ, то есть вдвое. LCP на замерах после изменений составляет 2,3 с, доля успешных проверок Core Web Vitals вырастает с 58 до 81 %.

Экономия в метрике складывается из двух частей. Крупный баннер в AVIF весит не 420, а 205 КБ, на мобильном интернете со скоростью около 10 Мбит/с это даёт примерно 0,2 с на передаче. Важнее очередь: когда 24 картинки конкурируют за канал, запрос баннера ждёт освобождения линии, и общее похудение страницы на 1,9 МБ разгружает канал почти на секунду.

Для поискового продвижения эффект двойной. Быстрый Largest Contentful Paint напрямую улучшает Core Web Vitals, а те входят в факторы ранжирования наряду с удобством страницы на телефоне. Поисковые роботы работают на движках современных браузеров и давно декодируют WebP и AVIF, поэтому картинки не выпадают из поиска изображений и не теряют позиции. Замеры до и после делают на одинаковых настройках канала, например медленный 4G с задержкой 150 мс, иначе сравнение ничего не докажет.

Порядок перехода на WebP и AVIF без риска для посетителей выглядит так:

1. собрать аудит картинок сайта и зафиксировать вес страниц и LCP до изменений;
2. сконвертировать десять типовых фотографий в AVIF и WebP с качеством 75–80 и сравнить кропы с JPEG;
3. добавить в шаблоны тег picture с порядком source от AVIF к WebP и запасным img в JPEG;
4. прогнать страницы через замеры скорости и убедиться, что вес и LCP упали, а макет не прыгает;
5. встроить конвертацию в сборку, чтобы каждая новая картинка сразу получала все три формата.

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