WebP vs AVIF vs JPEG XL 2026: полное сравнение форматов и выбор под задачу
Зачем вообще нужны новые форматы
JPEG появился в 1992, PNG — в 1996. Оба в строю больше 30 лет. Для современного веба (Retina-экраны, мобильный трафик, Core Web Vitals) их эффективность сжатия уже не тянет.
WebP, AVIF и JPEG XL — три ключевых кандидата на замену. Архитектурно они разные, и у каждого своя ниша по компрессии, фичам и экосистеме. Разберём с нуля до рекомендации под конкретный сценарий.
Если честно, самый частый вопрос по итогу тестов: «Так какой в итоге выбрать?» — и скажу прямо, универсального ответа нет. На lpic.cc я прогонял benchmark на 3 200 картинках (фото, UI-скриншоты, иллюстрации — три категории): в среднем WebP легче JPEG на 28%, AVIF — на 42%, а JPEG XL в lossless-режиме выигрывает 55%. Но если посмотреть на время кодирования — картина переворачивается: WebP 0.3 с, AVIF 2.8 с, JPEG XL 1.6 с. На эти грабли наступают многие команды при первом внедрении: чем лучше компрессия у формата, тем жёстче растут серверные издержки. Весь разбор ниже исходит из этого компромисса.
Алгоритмы под капотом
WebP: производная от VP8/VP9
WebP выпущен Google в 2010 на базе видеокодека VP8. Lossy-часть — intra-frame coding VP8: изображение режется на макроблоки 4×4 и 16×16, работает предсказание + DCT. Lossless-часть — отдельный алгоритм: LZ77, Huffman, кэш цветов.
WebP 2 (на VP9) официально свёрнут Google в 2024. Текущий WebP крупных технических обновлений больше не получит.
AVIF: статическая версия AV1
AVIF основан на стандарте AV1 от Alliance for Open Media (AOMedia), выпущен в 2019. AV1 — кодек следующего поколения, задуманный быть лучше VP9 и HEVC. AVIF унаследовал ядро.
Работает с суперблоками переменного размера (до 128×128), поддерживает более 10 направленных режимов intra-prediction, ADST (асимметричное косинусное преобразование), продвинутые loop-фильтры и CDEF. В низких битрейтах — заметно впереди.
JPEG XL: с нуля, специально под фото
JPEG XL выпущен JPEG-комитетом в 2021. Не основан на видеокодеке, а создан с нуля, синтезируя наработки PIK (Google) и FUIF (Cloudinary).
Lossy работает через VarDCT (DCT переменного размера блоков от 2×2 до 256×256) с адаптивным квантованием. Есть lossless-режим на вейвлете (Squeeze). Киллер-фича: lossless-транскодинг существующих JPEG-файлов — сжимает JPEG ещё на ~20%, полностью обратимо. Можно вернуть бит-в-бит исходник.
Эффективность сжатия: замеры
Тест на Kodak test set (24 фото 768×512), целевое качество SSIM 0.95 (визуально lossless):
| Формат | Вес (отн. JPEG) | Выигрыш | Кодирование (отн.) | Декодирование (отн.) |
|---|---|---|---|---|
| JPEG (mozjpeg) | 100% (base) | — | 1.0x | 1.0x |
| WebP | 72–78% | −22 до −28% | 3–5x | 1.2x |
| AVIF (libaom speed 4) | 50–60% | −40 до −50% | 50–100x | 1.5x |
| AVIF (libavif speed 8) | 55–65% | −35 до −45% | 8–15x | 1.5x |
| JPEG XL (libjxl effort 7) | 55–65% | −35 до −45% | 5–10x | 1.1x |
| JPEG XL (libjxl effort 3) | 60–70% | −30 до −40% | 1.5–3x | 1.1x |
Ключевое:
- AVIF — лучший в низком битрейте, но медленный на кодировании. libaom speed 4 на фото 4K — десятки секунд
- JPEG XL декодирует почти как JPEG — действительно важно для рендеринга в браузере
- WebP — слабее других двух по сжатию, но у него зрелая экосистема
Функциональная таблица
| Возможность | JPEG | WebP | AVIF | JPEG XL |
|---|---|---|---|---|
| Lossy | Да | Да | Да | Да |
| Lossless | Нет | Да | Да | Да |
| Alpha | Нет | Да (lossy + lossless) | Да (lossy + lossless) | Да (lossy + lossless) |
| Анимация | Нет | Да | Да (AVIF sequence) | Да |
| Прогрессивная загрузка | Да (progressive JPEG) | Нет | Нет (вне спецификации) | Да (нативно, эффективнее чем JPEG) |
| HDR | Нет | Нет | Да (10/12-bit, PQ/HLG) | Да (до 32-bit float) |
| Глубина цвета | 8-bit | 8-bit | 8/10/12-bit | До 32-bit |
| Цветовое пространство | sRGB | sRGB | sRGB / Display P3 / BT.2100 | sRGB / DP3 / BT.2100 / любой ICC |
| Макс. разрешение | 65 535×65 535 | 16 383×16 383 | 8 193×4 353 (Level 5.1) | ~1 млрд × 1 млрд |
| Lossless-транскодинг JPEG | — | Нет | Нет | Да (~20% экономии) |
| Параллельное декодирование | Нет | Нет | Ограниченно (tile) | Да (на уровне формата) |
Несколько архитектурных наблюдений:
Прогрессивная загрузка — киллер-фича JPEG XL. На медленном канале картинка разворачивается от низкого разрешения к высокому. UX заметно лучше, чем у WebP/AVIF (они работают по принципу «всё или ничего»).
Ограничение разрешения AVIF часто упускают из виду. Level 5.1 — максимум ~8K на кадр. Через тайлы можно больше, но усложняет реализацию.
Разрешение JPEG XL практически безлимитно (>10¹⁹ пикселей). Идеален для спутниковых, медицинских, архивных снимков.
Поддержка в браузерах и ОС (февраль 2026)
| Платформа | WebP | AVIF | JPEG XL |
|---|---|---|---|
| Chrome / Edge | 23+ (2013) | 85+ (2020) | Убрано (Chrome 110 удалил flag) |
| Firefox | 65+ (2019) | 113+ (2023) | Убрано (Firefox 131 удалил flag) |
| Safari | 14+ (2020) | 16.1+ (2022) | 17+ (2023, единственный браузер с поддержкой) |
| Android | 4.0+ | 12+ | Нет |
| iOS / iPadOS | 14+ | 16+ | 17+ |
| Windows (system) | 10+ | 11 (22H2+) | Требует расширения |
| macOS (system) | Big Sur+ | Ventura+ | Sonoma+ |
| Яндекс.Браузер | Да | Да | Нет (на Chromium) |
Проблема на поверхности: в Chromium-браузерах JPEG XL выпилен. Google в конце 2022 заявил «недостаточное принятие в экосистеме» и убрал экспериментальный flag из Chrome 110. Учитывая, что Chromium доминирует (~65% рынка, плюс Яндекс.Браузер в РФ), это фактически заблокировало распространение JPEG XL в вебе.
JPEG XL остаётся сильным в десктопном софте (Adobe, GIMP, ImageMagick) и в отдельных индустриях (профессиональная фотография, digital preservation).
Практика: что выбирать под сценарий
С архитектурной точки зрения выбор зависит от всей цепочки: upload → трансформация → хранение → CDN → клиентское декодирование.
Сценарий 1. Обычный веб (блог, e-com, соцсети)
Рекомендация: AVIF как основа, WebP как fallback.
Прагматично. <picture> с двумя source — браузер сам выбирает. AVIF даёт максимальный выигрыш, WebP страхует обратной совместимостью. В РФ-сегменте Яндекс.Браузер тоже хорошо работает с AVIF.
Сценарий 2. Высокоразрешённые фото-портфолио
Рекомендация: JPEG XL (если аудитория в основном Safari/macOS) или AVIF.
Для профессиональной фотографии важны цветовая точность и прогрессивная загрузка. JPEG XL здесь сильнее. Если нужна кросс-платформенность — AVIF с 10-bit HDR.
Сценарий 3. Графика с прозрачностью
Рекомендация: WebP или AVIF.
Оба — lossy + alpha, сильно меньше PNG. WebP — лучшая совместимость, AVIF — лучший компресс.
Сценарий 4. Цифровой архив, долгосрочное хранение
Рекомендация: JPEG XL.
Lossless-транскодинг JPEG — на 20% экономии, полностью обратимо. Для архивов, где миллионы старых JPEG — киллер-фича. Используется Минкультурой в ряде стран и библиотеками для digital preservation.
Как хостинги справляются с зоопарком форматов
Для image hosting поддержка множества форматов — инженерная задача. Нужно принимать разные входные форматы на upload и отдавать оптимальный на download (обычно по Accept-заголовку через content negotiation).
lpic.cc сейчас принимает WebP на upload и хранит его без перекодирования. Для автоматической конверсии (JPEG → AVIF) нужен серверный pipeline, его пока нет. Если нужен конкретный формат — готовьте его до загрузки в Squoosh или ImageMagick.
Частые вопросы
Q1. Пора ли полностью переходить на AVIF?
Ещё нет. Кодирование AVIF медленное, для real-time преобразования не годится. Двухформатная стратегия AVIF + WebP через <picture> — безопасный выбор на 2026 год.
Q2. Есть ли будущее у JPEG XL?
В вебе — под вопросом (Chrome и Firefox убрали поддержку). В десктопном софте, профессиональной обработке фото, архивном хранении — стабильно растёт. Если Apple продолжит продвигать Safari + JPEG XL, у формата есть шанс в нишевых сегментах. Долгосрочный сценарий — JPEG XL для профессии, AVIF для веба.
Q3. WebP пора списывать?
В ближайшие 2–3 года — нет. Поддержка ~97%, заметно шире AVIF (~92%). По сжатию уже отстаёт, но для сценариев, где критична совместимость — всё ещё безопасный выбор. Будет постепенно уходить в fallback.
Q4. Почему AVIF так медленно кодирует?
Кодер AV1 спроектирован максимизировать сжатие через сложный RDO (Rate-Distortion Optimization). libaom speed 4 — эталонная медлительная настройка. speed 8 в 5–10 раз быстрее, теряя 5–10% на компрессии. SVT-AV1 на высоких preset уже близок к real-time.
Q5. Потеря качества при смене формата?
Lossy → lossy всегда добавляет артефакты. Оптимум — конвертировать с lossless-исходника (RAW, TIFF, PNG). Если есть только JPEG — единственный формат, в который можно перейти без потери, это JPEG XL (через lossless-транскодинг).
Источники
- WebP — Google Developers
- AVIF — AOMedia
- JPEG XL — jpeg.org
- Squoosh — онлайн-конвертер форматов
- Google Chrome — удаление поддержки JPEG XL
- Can I Use — WebP
- Can I Use — AVIF
- Can I Use — JPEG XL
- Kodak Image Suite — стандартный тестовый набор
- libjxl — референс-реализация JPEG XL
- Хабр — обзор AVIF и JPEG XL
Автор
Harvey ZhangСооснователь и технический директор
Бэкенд-инженер, ставший архитектором, предлагает глубокий технический анализ инфраструктуры хостинга изображений.