JPEG XL в Chrome 155: стоит ли переводить изображения сайта на JXL

Chrome снова сделал JPEG XL практическим веб-форматом. Стабильный Chrome 155 вышел 6 октября 2026 года, а в Blink появилась штатная поддержка декодирования image/jxl через написанный на Rust декодер jxl-rs. Речь уже не о включении экспериментального флага: функция включена в release notes Chrome 155.

Для владельца сайта это важное изменение, но не команда немедленно пересобирать медиатеку. Поддержка декодирования отвечает лишь на вопрос «может ли браузер показать файл». Она ничего не говорит о том, умеет ли ваш WordPress принять JXL, сможет ли image library сформировать нужные размеры, сохранит ли CDN Content-Type, какой вариант окажется меньше при нужном качестве и изменится ли реальный LCP.

Что изменил JPEG XL в Chrome 155

Главное изменение — расширение практической браузерной базы JPEG XL. Safari умеет работать с форматом с версии 17, Chrome добавил его в 155, а Firefox 158 на дату подготовки материала находится в Beta и заявлен с JXL, включённым по умолчанию. Поэтому формат перестал быть технологией, которую можно было рассматривать только для узкой аудитории Apple, но fallback пока остаётся нормальной частью production-архитектуры.

Сам JPEG XL стандартизирован как семейство ISO/IEC 18181. Он поддерживает lossy и lossless compression, высокий bit depth, wide color gamut, HDR, alpha, animation и progressive coding. Отдельно интересна возможность без потерь перекодировать существующий JPEG в JXL, а затем восстановить исходный JPEG bit-for-bit. Для больших JPEG-архивов это принципиально иной сценарий, чем обычное повторное lossy-сжатие.

Команда Chrome указывает ориентир в 30–50% более эффективного сжатия по сравнению с JPEG, но эту цифру нельзя переносить на каждую фотографию сайта. В той же публикации разработчикам советуют пробовать и AVIF, и JPEG XL, а JXL особенно выделяют для high-fidelity, lossless-сценариев, фотографий и случаев, где важна детальная progressive decoding. То есть правильный вывод из Chrome 155 — «теперь JXL стоит тестировать», а не «JXL всегда уменьшит изображение на треть».

Где JXL силён и почему AVIF и WebP никуда не исчезают

Формат изображения выбирают не по поколению кодека, а по задаче и результатам на конкретном наборе исходников.

Формат	Где особенно полезен	Что учитывать
JPEG XL	качественные фотографии, high-fidelity, lossless, JPEG recompression, progressive delivery	новая production-цепочка должна быть проверена целиком
AVIF	lossy-фотографии и уже отлаженные современные image pipelines	в ряде изображений может оказаться выгоднее JXL
WebP	инфраструктурно зрелый современный формат, удобный дополнительный fallback	обычно не повод срочно удалять уже работающую WebP-цепочку
JPEG	максимально совместимый базовый fallback и существующие оригиналы	больший размер сам по себе не означает, что оригинал надо удалять

Здесь особенно опасно сравнивать только значение quality=80 у двух кодеков. Числовая шкала качества одного encoder не эквивалентна такой же шкале другого. Нормальный тест сравнивает файлы при сопоставимом визуальном качестве или выбранной объективной метрике и только затем смотрит на размер, скорость обработки и поведение страницы.

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

JPEG XL Chrome: три уровня поддержки вместо одной галочки

Для внедрения JXL полезно разделить три независимых слоя.

1. Browser decode

Браузер должен понимать image/jxl. Chrome 155 теперь выполняет эту часть задачи штатно. Safari поддерживает JPEG XL с Safari 17. При этом поддержка разных возможностей формата и темпы обновления клиентов не абсолютно одинаковы, поэтому раздавать JXL как единственный файл пока не требуется.

2. Server и CDN delivery

Следующий слой — доставка. Origin или CDN должен корректно отдавать .jxl с MIME-типом:

Content-Type: image/jxl

Минимальная проверка конкретного файла:

curl -I https://example.com/uploads/cover.jxl

Здесь важен не только HTTP 200. Нужно проверить Content-Type, cache headers, фактический размер ответа, отсутствие нежелательного перекодирования и поведение CDN при разных браузерах.

Если CDN выбирает формат через content negotiation или собственную image optimization, отдельно проверяйте cache key. Иначе есть риск создать ситуацию, когда один вариант изображения кэшируется и некорректно отдаётся клиентам с другой поддержкой.

3. CMS и image processing

Самая частая ошибка — считать, что браузерная поддержка автоматически превращает JXL в полноценный формат WordPress.

Во время разработки WordPress 7.1 JPEG XL действительно тестировался в client-side media processing. Однако незавершённая JXL-функциональность была вынесена из scope 7.1, а опубликованный dev note для client-side processing перечисляет фиксированный набор JPEG, PNG, GIF, WebP и AVIF. Поэтому нельзя закладывать в архитектуру предположение «WordPress 7.1 сам всё сделает с .jxl».

Проверять надо конкретно:

• принимает ли Media Library файл;
• определяет ли его MIME корректно;
• создаются ли registered image sizes;
• работает ли crop;
• формируется ли srcset;
• переживает ли формат regenerate thumbnails;
• сохраняются ли metadata;
• понимают ли JXL плагины оптимизации и CDN;
• что произойдёт при откате на JPEG/AVIF.

Как давать JXL браузеру без риска для остальных посетителей

Для обычного <img> безопасная модель — progressive enhancement через <picture>. Браузер последовательно проверяет <source> и выбирает первый формат, который умеет использовать; если подходящего источника нет, остаётся src у <img>. Этот механизм применяется и для AVIF/WebP fallback.

Например, для контролируемого теста JXL:

<picture>
  <source
    type="image/jxl"
    srcset="
      /media/cover-800.jxl 800w,
      /media/cover-1280.jxl 1280w,
      /media/cover-1600.jxl 1600w
    "
  >

  <source
    type="image/avif"
    srcset="
      /media/cover-800.avif 800w,
      /media/cover-1280.avif 1280w,
      /media/cover-1600.avif 1600w
    "
  >

  <source
    type="image/webp"
    srcset="
      /media/cover-800.webp 800w,
      /media/cover-1280.webp 1280w,
      /media/cover-1600.webp 1600w
    "
  >

  <img
    src="/media/cover-1280.jpg"
    srcset="
      /media/cover-800.jpg 800w,
      /media/cover-1280.jpg 1280w,
      /media/cover-1600.jpg 1600w
    "
    sizes="(max-width: 768px) 100vw, 1280px"
    width="1600"
    height="900"
    fetchpriority="high"
    alt="..."
  >
</picture>

Порядок <source> — это приоритет. Если JXL стоит первым, поддерживающий его браузер выберет JXL, даже когда AVIF для конкретного изображения оказался меньше. Поэтому production-порядок тоже должен определяться тестом.

srcset и sizes при этом не теряют значения. Современный кодек не исправляет ситуацию, когда мобильному экрану передают 2500-пиксельный cover. Responsive images сокращают лишнюю передачу данных и могут уменьшить resource load duration LCP-изображения.

Практический сценарий: WordPress-сайт с крупными cover images

Представим WordPress-проект, где главная проблема медиабюджета — крупные фотографические обложки статей. Уже есть WebP или AVIF, а JXL рассматривается после появления поддержки в Chrome 155.

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

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

Проверка	Что сравнивать
Вес	фактические bytes каждого файла
Визуальное качество	артефакты, детали, градиенты, цвет
Responsive delivery	правильность srcset и выбранного размера
LCP	field data на страницах, где cover является кандидатом LCP
Надёжность	ошибки загрузки и декодирования
CDN	cache hit и отсутствие неверной раздачи формата
CMS	генерация размеров, crop, regenerate, rollback

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

На WordPress особенно важно не превращать новый delivery-формат в единственную копию оригинала до подтверждения всех операций медиатеки. Возможность браузера открыть .jxl и возможность CMS безопасно редактировать, пересоздавать и мигрировать такой asset — разные вещи.

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

Почему меньший JXL не гарантирует лучший LCP

Размер файла имеет значение. Для изображения, которое является LCP-ресурсом, уменьшение transfer size способно сократить resource load duration. Google прямо включает современный формат и сжатие в способы оптимизации LCP. Но загрузка самого файла — только одна фаза метрики.

Можно получить JXL на 15% меньше текущего файла и почти не увидеть изменения field LCP, если основная задержка возникает раньше: изображение поздно обнаруживается, вставляется JavaScript, спрятано в CSS, получает низкий приоритет или ожидает медленный origin.

Для hero/LCP изображения по-прежнему важнее вся последовательность:

1. URL должен быть рано обнаружим из HTML.
2. Нельзя применять loading="lazy" к основному LCP-изображению.
3. При необходимости используется fetchpriority="high".
4. Размер варианта должен соответствовать viewport.
5. Сервер и CDN не должны добавлять лишнюю задержку.
6. Только затем имеет смысл сравнивать разницу между AVIF и JXL.

fetchpriority="high" способен ускорить получение критичного изображения, потому что повышает его относительный сетевой приоритет. Поэтому изменение кодека нужно измерять отдельно от изменений discovery и priority — иначе эксперимент покажет улучшение, но вы не поймёте, что именно его вызвало.

Какие field metrics смотреть после выката

Для решения о расширении JXL достаточно трёх основных групп данных.

Bytes

Сравнивайте реальный объём передачи одного и того же класса изображений. Интересует не вес случайного файла на диске, а то, какой вариант фактически получает посетитель при его viewport и DPR.

LCP

Смотрите полевые данные отдельно для страниц, где cover действительно является LCP-кандидатом. Желательно сегментировать результат хотя бы по типу устройства и браузерной группе. Если JXL уменьшил bytes, но p75 LCP статистически не изменился, не надо превращать уменьшение файла в заявление об улучшенных Core Web Vitals.

Error rate

Нужны ошибки загрузки и декодирования: img.onerror, ответы origin/CDN, неожиданные MIME-типы, 404 на отдельных subsizes и проблемы после purge/regenerate.

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

Стоит ли переходить на JPEG XL сейчас

Для сайта с большим количеством фотографий ответ скорее «начать тестировать», чем «перейти».

JXL уже имеет реальную ценность, когда:

• изображения составляют существенную часть transfer size;
• важна высокая визуальная точность;
• есть lossless-сценарии;
• хранится большой JPEG-архив;
• полезна progressive delivery;
• есть возможность контролировать CDN и генерацию вариантов;
• команда умеет измерять результат в field data.

Оставить AVIF/WebP основным production-вариантом разумно, когда текущая система уже даёт хорошие размеры и стабильный LCP, а CMS или CDN пока не поддерживает JXL без дополнительных обходных решений.

Chrome 155 снимает один из главных барьеров JPEG XL, но не отменяет инженерный принцип: формат изображения — часть delivery pipeline. Пока не проверены encoder, CMS, origin/CDN, browser fallback и реальные метрики пользователей, расширение .jxl само по себе ничего не доказывает.