JPEG XL vs AVIF: Какой формат выбрать для продакшена?

Для веб-доставки в продакшене в 2026 году используйте AVIF: по состоянию на середину 2026 года он охватывает около 93% браузеров по всему миру и имеет зрелую поддержку со стороны CDN, CMS и инструментов сборки. JPEG XL технически превосходит AVIF — быстрее кодирует, значительно лучше работает в режиме без потерь, поддерживает нативное прогрессивное декодирование — однако Chrome по-прежнему включает его только через флаг, из-за чего покрытие JXL составляет около 15%, и только через Safari, который caniuse классифицирует как частичную поддержку. Именно этот факт решает вопрос для любого публичного сайта: пока Chrome не включит JXL по умолчанию, стек доставки с приоритетом JXL всё равно будет отдавать AVIF или JPEG подавляющему большинству пользователей.

Эта статья напрямую отвечает на вопрос в промежуточной ситуации: вы уже раздаёте WebP или AVIF, знаете об ограничениях JPEG и хотите принять обоснованное решение, опираясь на реальное состояние браузеров, а не на продвижение того или иного формата. Мы разберём каждый критерий — сжатие, поддержка браузеров, стоимость кодирования, прогрессивный рендеринг — приведём корректный сниппет <picture> и укажем конкретный сигнал, при котором рекомендация изменится.

Что представляет собой каждый формат

AVIF и JPEG XL решают одну задачу — уменьшить размер изображений при равном или лучшем качестве — но происходят из принципиально разных концепций. AVIF (AV1 Image File Format) был представлен Alliance for Open Media в 2019 году и основан на внутрикадровом кодировании видеокодека AV1, который используют такие сервисы, как YouTube и Netflix. JPEG XL (ISO/IEC 18181) был создан специально как формат для статичных изображений совместно Объединённой группой экспертов по фотографии, Google и Cloudinary и стандартизирован в 2022 году.

Это различие в происхождении — AVIF унаследован от видеокодека, JPEG XL создан специально для статичных изображений — объясняет большинство компромиссов, описанных ниже. AVIF наследует сильное сжатие фотографий с потерями от AV1 и его вычислительно затратный кодировщик. JPEG XL был разработан с учётом специфики изображений: прогрессивное декодирование, высокая битовая глубина цвета, режимы без потерь и одна функция, которой нет ни в одном другом современном формате, — сжатие JPEG без потерь. Существующий JPEG можно перекодировать в JXL, уменьшив размер файла примерно на 20%, и восстановить исходный JPEG побайтово. Это делает JXL единственным жизнеспособным форматом для архивирования больших библиотек JPEG без потери качества — реальный критерий выбора, а не просто примечание.

Сжатие: победитель зависит от контента

AVIF выигрывает при сжатии фотографий с потерями на низком и среднем качестве; JPEG XL выигрывает при высоком качестве, на нефотографическом или графическом контенте, а также однозначно побеждает в режиме без потерь. Не существует единственного ответа «X на N% меньше», и любая статья, которая его даёт, преувеличивает результат, зависящий от конкретного контента.

Практическая разбивка:

• Сжатие фотографий с потерями, среднее качество: потери AVIF при агрессивных битрейтах выглядят мягче и естественнее — он размывает края и скрывает артефакты там, где режим VarDCT в JPEG XL может давать звон или блочность, характерные для классического JPEG. Это родная стихия AVIF и наиболее распространённый веб-сценарий.
• Высокое качество и нефотографический контент: JPEG XL не уступает AVIF или превосходит его, особенно на иллюстрациях, логотипах, скриншотах и графике с большим количеством текста, где его модульный режим кодирования чисто обрабатывает области с однородным цветом.
• Без потерь: JPEG XL однозначно лучше. Lossless AVIF практически неприменим — он едва превосходит PNG, — тогда как lossless JXL конкурентоспособен с PNG и нередко значительно меньше по размеру.

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

Поддержка браузеров: решающий фактор

Поддержка браузеров — это то, где решение фактически принимается, и именно этот фактор большинство справочных статей освещают неверно или приводят устаревшие данные. По состоянию на середину 2026 года AVIF охватывает около 93% браузеров по всему миру и включён по умолчанию в Chrome, Edge, Firefox и Safari. JPEG XL находится примерно на 15% охвата — исключительно через Safari, и классифицируется как частичная поддержка.

История Chrome важна, поскольку две из трёх наиболее цитируемых статей излагают её неверно. Точная хронология:

Широко распространённое утверждение о том, что Chrome «прекратил поддержку» JPEG XL, устарело. Chromium отозвал статус устаревшего для этого формата и повторно интегрировал декодирование с использованием нового декодера на Rust вместо C++-библиотеки libjxl. Однако повторная интеграция — это не то же самое, что выпуск: в текущем стабильном канале декодирование JXL в Chrome по-прежнему отключено по умолчанию и требует ручной активации через chrome://flags/#enable-jxl-image-format. Firefox содержит код JXL в Nightly за флагом image.jxl.enabled, но не включает его в релизные сборки и не публиковал никаких сроков выпуска.

Перевод этого в практическое решение о выпуске — это то, что каждая справочная статья подразумевает, но ни одна не формулирует чётко: элемент <picture> с приоритетом JXL сегодня отдаёт AVIF или JPEG примерно 85% ваших пользователей. Вы кодируете и храните три варианта формата, чтобы доставить JXL примерно каждому седьмому посетителю — и даже этот охват представляет собой лишь частичную поддержку только в Safari. Такова реальная стоимость перехода на JXL прямо сейчас, и она оправдает себя только после того, как Chrome включит формат по умолчанию.

Стоимость кодирования и прогрессивный рендеринг

JPEG XL кодирует быстрее, чем AVIF, и уникально поддерживает прогрессивное декодирование; кодирование AVIF требует значительных ресурсов CPU и не имеет настоящего прогрессивного режима. Оба различия операционно значимы — одно влияет на пайплайн сборки, другое — на воспринимаемое время загрузки для пользователей.

Кодирование AVIF — медленный этап в большинстве пайплайнов

Кодирование AVIF с помощью референсного кодировщика AV1 (libaom-av1) является самым медленным этапом в типичном пайплайне обработки изображений — заметно медленнее на изображение, чем JPEG XL при эквивалентном перцептивном качестве. Для единичного изображения-баннера, конвертируемого вручную, это несущественно. Но для CI-задачи, обрабатывающей сотни изображений продуктов при каждом деплое, это реальное ограничение: время кодирования растёт пропорционально количеству изображений, а кодировщик AV1 намеренно вычислительно затратен.

Практические способы оптимизации для Node.js-пайплайна:

• Используйте Sharp, который оборачивает libvips, для кодирования AVIF и JXL. Он предоставляет параметры quality и effort, позволяющие балансировать между временем кодирования и размером выходного файла.
• Настраивайте параметр effort/speed вместо запуска кодировщика с максимальными усилиями по умолчанию — кодирование AVIF с высоким effort даёт незначительно меньшие файлы при большом росте времени.
• Распараллеливайте по рабочим потокам или ядрам CPU, либо перенесите конвертацию на CDN с кодированием на лету, чтобы это никогда не блокировало сборку.

const sharp = require("sharp");

// AVIF: более низкий `effort` немного увеличивает размер, но значительно ускоряет CI-кодирование
await sharp("hero.png")
  .avif({ quality: 60, effort: 4 })
  .toFile("hero.avif");

// JXL кодирует быстрее при сопоставимом качестве (требует сборки с поддержкой libjxl)
await sharp("hero.png")
  .jxl({ quality: 60 })
  .toFile("hero.jxl");

Проверьте доступность форматов в установленной сборке sharp с помощью sharp.format — поддержка JXL зависит от встроенных libvips/libjxl и не гарантируется в каждом дистрибутиве.

Прогрессивное декодирование влияет на воспринимаемый LCP

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

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

Фреймворк принятия решений: используйте X, если…

Используйте AVIF сейчас для публичного веба в продакшене с фолбэками на WebP и JPEG через <picture>. Обращайтесь к JPEG XL в конкретных, ограниченных случаях: рабочие процессы без потерь или архивирование, библиотеки нефотографических изображений, аудитория с преобладанием Safari или большие архивы JPEG, которые нужно перекодировать без потери качества.

Используйте AVIF, если:

• Вы управляете публичным продакшен-сайтом, которому нужен широкий охват уже сегодня.
• Ваши ресурсы преимущественно фотографические или смешанные.
• Вы используете CMS или CDN с нативной поддержкой — AVIF нативно поддерживается в WordPress начиная с WP 6.5 (апрель 2024), а крупные CDN кодируют его на лету.
• Вы хотите измеримого улучшения LCP по сравнению с JPEG/WebP без необходимости управлять четвёртым вариантом формата.

Обратитесь к JPEG XL, если:

• Вы ведёте большой архив JPEG и хотите перекодировать без потерь — конвертируйте в JXL (~20% экономии) и восстанавливайте оригиналы побайтово.
• Ваш контент преимущественно нефотографический: иллюстрации, логотипы, диаграммы, скриншоты.
• Ваша аудитория преимущественно использует Safari, и вы полностью контролируете разметку <picture> в headless или кастомной конфигурации.
• Вы создаёте перспективную систему доставки на момент, когда Chrome включит JXL по умолчанию.

JPEG XL не имеет нативной поддержки загрузки в WordPress по состоянию на середину 2026 года, что дополнительно подкрепляет AVIF как практический выбор для CMS.

Корректный актуальный сниппет <picture>

В элементе <picture> браузер оценивает записи <source> в порядке их следования в документе и выбирает первый поддерживаемый тип type, возвращаясь к <img>, если ни один не подходит. Порядок поэтому не является косметическим — это алгоритм выбора. Перечисляйте форматы от лучшего к худшему по вашему приоритету, а фолбэком для <img> делайте JPEG с универсальной поддержкой, а не WebP (WebP требует собственной записи <source>, поскольку является отдельным MIME-типом).

<picture>
  <!-- JXL первым: отдаётся только Safari 17+ (частично); в Chrome отключён флагом в середине 2026 -->
  <source srcset="hero.jxl" type="image/jxl">
  <!-- AVIF: ~93% охвата, основной уровень для почти всего трафика -->
  <source srcset="hero.avif" type="image/avif">
  <!-- WebP: охватывает старые Chrome/Firefox без поддержки AVIF -->
  <source srcset="hero.webp" type="image/webp">
  <!-- JPEG: безусловный фолбэк; src, который всегда отображается -->
  <img src="hero.jpg" alt="Описание" width="1200" height="630"
       loading="lazy" decoding="async">
</picture>

Честная оценка этого четырёхуровневого стека: сегодня он обходится вам в четыре закодированных варианта, чтобы отдать JXL Safari-ориентированному меньшинству. Если ваша аудитория не сосредоточена в Safari и у вас нет архивных причин для JXL, уберите первый <source> и используйте трёхуровневую версию AVIF/WebP/JPEG — она охватывает почти весь трафик с одним форматом меньше для сборки и хранения. Добавляйте JXL source тогда, когда Chrome переключит флаг, — но не раньше.

На что обращать внимание, чтобы изменить рекомендацию

Практическим триггером для перехода на JPEG XL как основной формат доставки станет включение chrome://flags/#enable-jxl-image-format в Chrome по умолчанию; пока этого не произошло, математика охвата — около 15% JXL (только Safari, частичная поддержка) против ~93% AVIF — оставляет AVIF единственным обоснованным основным форматом для публичного веба в продакшене. Конкретные сигналы, заслуживающие мониторинга:

• Изменение записи Chrome Platform Status для JPEG XL с «за флагом» на «выпущен/включён по умолчанию».
• Охват полной поддержки на caniuse.com/jpegxl, пересекающий используемый порог и теряющий обозначение partial.
• Переход JXL в Firefox из Nightly в релизную сборку.
• Включение конвертации JXL по умолчанию в пайплайнах обработки изображений крупными CDN.

Когда произойдёт первое из этих событий, стек <picture> с приоритетом JXL перестанет быть умозрительными затратами и станет рекомендацией по умолчанию, а приведённый выше фреймворк инвертируется.

Заключение

Используйте AVIF сегодня и держите разметку <picture> готовой к JPEG XL. AVIF — это формат, который достигает ваших пользователей прямо сейчас, с инструментарием и поддержкой CMS в придачу; JPEG XL технически превосходит его и является правильным инструментом для lossless-архивов и перекодирования JPEG, но его применимость в публичном вебе полностью зависит от включения по умолчанию в Chrome. Конвертируйте ресурсы в AVIF, добавьте фолбэки на WebP и JPEG и следите за записью в Chrome Platform Status — в день, когда этот флаг будет включён по умолчанию, стоит пересмотреть JXL как основной формат.

Часто задаваемые вопросы

Увеличивает ли использование AVIF и JXL source в одном элементе picture мои расходы на хранение и трафик вдвое?

Это увеличивает расходы на хранение, но не на трафик запросов. Каждый вариант формата, который вы перечисляете, добавляет закодированный файл для хранения, поэтому четырёхуровневый стек JXL/AVIF/WebP/JPEG означает четыре хранимых файла на изображение. Трафик не затрагивается, поскольку браузер загружает только первый поддерживаемый source, который он выбирает, но никогда не несколько вариантов одновременно. Реальная стоимость стека с приоритетом JXL — это дополнительное кодирование и хранение для охвата Safari-ориентированного меньшинства, а не дублирование загрузок.

Можно ли конвертировать изображения AVIF в JPEG XL позже без перекодирования из оригинала?

Нет, без потери качества это невозможно. Сжатие JPEG без потерь в JPEG XL уникально именно для JPEG-источников, а не для AVIF или WebP. Вы можете обернуть существующий JPEG в JXL и восстановить его побайтово, но AVIF и WebP являются форматами с потерями и не имеют такого обратимого пути. Конвертация AVIF в JXL означает декодирование уже сжатого AVIF и его повторное кодирование, что накапливает артефакты. Всегда сохраняйте исходные мастера без потерь, чтобы иметь возможность чисто перекодировать в любой формат.

Почему моё AVIF-изображение баннера по-прежнему ухудшает Largest Contentful Paint, хотя файл меньше, чем JPEG?

AVIF не имеет настоящего прогрессивного декодирования, поэтому большое AVIF-изображение отображается только после полной загрузки файла, а не рендерит сначала предварительный просмотр низкого качества. На медленном соединении слот баннера остаётся пустым на всё время загрузки, а временная метка LCP фиксируется в момент финальной отрисовки. Меньший общий размер файла не меняет это поведение «всё или ничего». Прогрессивное декодирование JPEG XL улучшает изображение постепенно, что повышает воспринимаемую скорость загрузки даже при сопоставимом количестве байт.

Выберет ли браузер, поддерживающий и AVIF, и JPEG XL, тот source, который я указал первым?

Да. Элемент picture выбирает первый source, атрибут type которого поддерживается браузером, оцениваемый в порядке следования в документе, независимо от размера файла или возможностей формата. Если вы указываете JXL перед AVIF, сборка Safari, поддерживающая оба формата, отдаёт JXL; поменяйте порядок — и она отдаст AVIF. Браузер не сравнивает качество или вес, поэтому порядок source является механизмом выбора. Размещайте предпочтительный формат первым и завершайте универсально поддерживаемым фолбэком img с JPEG.