Сколько раз за последние годы тебе доводилось слышать, что эпоха зоопарка форматов графики в вебе наконец подошла к концу? Сначала нам обещали, что WebP навсегда вытеснит старый добрый JPEG. Затем на сцену вышел AVIF — и все заговорили о невероятных коэффициентах сжатия видеокодека AV1, упакованного в неподвижные картинки. А следом в стандарты ворвался JPEG XL, переживший драматичную историю: сначала его удалили из экспериментальных сборок Chromium, а затем, под давлением сообщества и после внедрения в Safari и Firefox, с триумфом вернули обратно в браузеры.
Когда вокруг форматов столько шума, легко впасть в одну из двух крайностей: либо упрямо сидеть на классическом JPEG образца 1992 года, либо сломя голову конвертировать всю медиатеку в «самый модный» формат. Известный веб-инженер Джейк Арчибальд (Jake Archibald) решил проверить реальное положение дел на практике и провел масштабное сравнительное исследование JPEG XL и AVIF на реальных изображениях своего блога на тестовом MacBook Pro M4 Pro. Для объективности использовалась строгая перцептивная метрика качества SSIMULACRA 2. Я внимательно изучил эти данные, и давай разберем по винтикам, как форматы ведут себя «под капотом» и почему они не убивают друг друга, а идеально делят веб пополам.
Иллюзия абсолютной победы: где AVIF уходит в отрыв
Начнем с самого болезненного вопроса: размера файла при сжатии с потерями (lossy). Если открыть презентацию сторонников любого нового формата, тебе покажут графики с невероятным выигрышем. Но на реальных фотографиях поведение энкодеров преподносит сюрпризы.
При настройках по умолчанию AVIF стабильно генерирует файлы на 15–25% компактнее, чем JPEG XL при аналогичном визуальном балле качества по шкале SSIMULACRA 2. Если выкрутить ползунки сжатия на максимум (заставив энкодер часами перебирать векторы предсказания), разрыв сокращается, но AVIF все равно удерживает преимущество в 6–20%.
Но настоящая пропасть открывается там, где речь заходит об интерфейсной графике, скриншотах программ и векторных иллюстрациях с четкими краями:
- На скриншотах интерфейсов и графиках файлы JPEG XL оказываются на 30–90% тяжелее AVIF при стандартных усилиях кодирования.
- В изображениях с прозрачным альфа-каналом эталонная библиотека
libjxlвыдает файлы на 31–44% больше при дефолтных параметрах. Новый Rust-энкодерjixelот разработчикаawxkeeкодирует прозрачность строго без потерь, из-за чего его файлы с полупрозрачными градиентами могут весить в 2–3 раза больше, чем компактный AVIF.
Почему так происходит? AV1 разрабатывался как видеокодек: его алгоритмы оптимизированы под разбиение картинки на крупные однородные блоки и интеллектуальное сглаживание плоских областей. Если на скриншоте есть однотонный фон окна или кнопка с плоской заливкой, AVIF схлопывает ее буквально в пару байтов. JPEG XL ориентирован на сохранение естественных частотных характеристик, поэтому на плоских синтетических поверхностях тратит лишние биты.
Обратная сторона медали: пластиковое мыло против живого кадра
Казалось бы, если AVIF сжимает сильнее, зачем вообще нужен JPEG XL? И вот здесь мы подходим к главной инженерной драме.
Попробуй внимательно вглядеться в высокодетализированную фотографию, пожатую в AVIF на среднем качестве: текстура ткани, мелкая листва на деревьях, поры кожи или зернистость пленочного кадра. Что с ними происходит? Алгоритм сглаживания AV1 безжалостно затирает микроструктуры, создавая характерный «эффект пластилина» или размытой акварели. Глаз сразу чувствует неестественность, даже если формально метрики шума остаются в норме.
JPEG XL устроен принципиально иначе. Его математический аппарат (включая работу в цветовом пространстве XYB и адаптивное квантование) проектировался именно под психологию человеческого зрения и фотографическую оптику. Он сохраняет естественное зерно и резкие микроконтрасты даже на умеренных битрейтах. На тяжелых фотографиях высокого разрешения для интернет-магазинов одежды, интерьерных галерей или портфолио фотографов JPEG XL выглядит на порядок естественнее и живее, чем AVIF.
Секретное оружие: перепаковка JPEG без единой потери
Есть одна особенность JPEG XL, которой нет и никогда не будет у AVIF. Это возможность реверсивной перепаковки существующих файлов JPEG без потерь.
Представь: у тебя есть файловое хранилище на сотни гигабайт или терабайты старых фотографий в формате .jpg. Если ты решишь пережать их в AVIF или WebP, произойдет транскодирование с потерями: артефакты старого сжатия наложатся на артефакты нового, а качество неизбежно деградирует.
JPEG XL умеет считывать исходные коэффициенты дискретного косинусного преобразования (DCT) обычного JPEG и упаковывать их в более плотный бинарный контейнер с использованием современного энтропийного кодирования ANS.
- Размер файла уменьшается на 9–20% просто «из воздуха».
- Картинка не теряет ни одного бита информации.
- В любой момент этот файл можно мгновенно распаковать обратно в побайтово идентичный исходный JPEG!
Для облачных CDN и медиасерверов это колоссальная экономия трафика и дискового пространства без малейшего риска испортить исходники клиентов.
Прогрессивный рендеринг и скорость в браузерах
Еще один критический аспект для веб-разработки — скорость отображения контента. Как отмечалось, когда состоялся Релиз Chrome 155: возвращение JPEG XL, CSS-функция symbols() и текстовые модули в JS, поддержка прогрессивной отрисовки стала ключевым фактором пользовательского опыта на мобильных сетях.
JPEG XL поддерживает по-настоящему красивый прогрессивный рендеринг: браузер сперва отрисовывает низкочастотный эскиз всей страницы (пространственный слой DC), а затем по мере поступления байтов плавно насыщает картинку резкими деталями. При использовании энкодера jixel включение прогрессивного режима на высоких усилиях сжатия практически не увеличивает размер файла.
Однако на уровне браузерных движков ситуация пока неоднородна:
- Google Chrome и Mozilla Firefox отлично справляются с прогрессивным отображением JPEG XL.
- Apple Safari пока отрисовывает изображение целиком только после завершения загрузки сетевого пакета.
- Кроме того, в современных процессорах (Apple M3/M4, Intel Core Ultra, AMD Ryzen) есть встроенные аппаратные декодеры AV1, поэтому AVIF декодируется силами кремниевых блоков в 2–3 раза быстрее и почти не расходует батарею мобильного устройства. JPEG XL сегодня почти везде декодируется программно (хотя и делает это очень быстро за счет эффективного SIMD-кода).
Не пытайся выбрать «одного победителя на все случаи жизни». Оптимальная архитектура современной доставки графики делится на два четких сценария:
- Для скриншотов документации, векторных иллюстраций, логотипов с полупрозрачностью и карточек товаров малого разрешения отдавай AVIF — здесь он бьет рекорды компактности.
- Для полноэкранных фотографий, фотогалерей высокого разрешения, баннеров с глубокой текстурой и сжатия существующих архивов отдавай JPEG XL через элемент
<picture>с фолбеком на AVIF и JPEG.
В итоге перед нами не битва на уничтожение, а долгожданная зрелость веб-платформы. Инструменты наконец заняли свои естественные ниши, и грамотный инженер может выжимать максимум скорости загрузки и качества картинки, комбинируя сильные стороны обоих форматов.