JPEG XL e Core Web Vitals: o que você precisa saber agora que o Chrome o suporta

O JPEG XL está finalmente voltando ao Chrome

Após três anos de controvérsia, o JPEG XL retornou ao Chromium. O Chrome 145, lançado no início de fevereiro de 2026, vem com um decodificador JPEG XL. Ainda atrás de uma flag, mas funcionalmente presente no código pela primeira vez desde sua controversa remoção no final de 2022. Isso importa porque o JPEG XL é comprovadamente superior a todos os formatos de imagem web existentes na maioria das dimensões técnicas: 50 a 60% menor que JPEG, 10 a 15% melhor compressão que AVIF em velocidades de codificação equivalentes, e o único formato moderno com verdadeira decodificação progressiva. Para profissionais de desempenho web, a trajetória do formato, de padrão ISO ao exílio do Chrome e à ressurreição, representa tanto uma oportunidade técnica quanto um alerta sobre o poder dos fornecedores de navegadores sobre a plataforma web.

Última revisão por Arjen Karel em fevereiro de 2026

O suporte de navegadores em fevereiro de 2026 é de apenas 12%

O suporte efetivo global de navegadores para JPEG XL está em aproximadamente 12%, quase inteiramente de usuários do Safari. Esse número está prestes a mudar. Mas o cronograma permanece incerto.

Safari 17+ (lançado em setembro de 2023) fornece decodificação nativa de JPEG XL em macOS Sonoma, iOS 17, iPadOS 17, watchOS e visionOS. A implementação da Apple delega a decodificação ao framework de imagem do nível do sistema operacional, o que significa que funciona em todos os lugares onde o Safari roda. No entanto, o suporte do Safari é explicitamente parcial: sem suporte a animações e sem decodificação progressiva. Duas das características mais distintivas do JPEG XL. Esta é uma limitação significativa que enfraquece a proposta de valor completa do formato nos dispositivos Apple.

Chrome 145 (fevereiro de 2026) reintroduz o JPEG XL via um decodificador em Rust puro chamado jxl-rs, substituindo a implementação anterior em C++ libjxl. O decodificador está protegido atrás de chrome://flags/#enable-jxl-image-format e não está habilitado por padrão. O Google estabeleceu condições claras para a habilitação padrão: um compromisso com a manutenção a longo prazo e o cumprimento dos critérios padrão de lançamento. O decodificador Rust atualmente tem desempenho dentro de 15 a 25% da velocidade da implementação de referência em C++, com 26 PRs de otimização mesclados apenas em dezembro de 2025. As capacidades confirmadas incluem perfis de cor ICC, animações, alfa/transparência, ampla gama de cores (Display P3) e HDR (PQ/HLG).

Para experimentar o JPEG XL no Chrome hoje, navegue até chrome://flags/#enable-jxl-image-format e defina como Enabled. Reinicie o Chrome. Qualquer site que já serve imagens JXL (clientes da Cloudinary, por exemplo) começará a entregá-las ao seu navegador.

Firefox permanece o mais atrasado. O formato está disponível apenas no Firefox Nightly atrás da flag image.jxl.enabled. Criticamente, o código do decodificador não é compilado nas builds estáveis, então a flag não faz nada no Firefox de lançamento. A posição da Mozilla mudou de "negativa" para "neutra". O decodificador Rust jxl-rs foi integrado ao Firefox Nightly (visando o Firefox 149), mas seis bloqueadores permanecem antes que possa ser lançado na versão estável: suporte a perfis de cor, decodificação progressiva, HDR, integração com profiler, compilação em builds de lançamento e aprovação nos Web Platform Tests. Não existe cronograma para suporte na versão estável.

Edge, como derivado do Chromium, provavelmente contém o código jxl-rs do Chrome 145, mas não anunciou ou documentou oficialmente o suporte a JPEG XL. As notas de lançamento do Edge 145 não mencionam isso.

Interop 2026 incluiu o JPEG XL como uma área de investigação (não uma área de foco completa), com Apple, Google, Microsoft e Mozilla participando. Isso sinaliza intenção entre fornecedores de construir suítes de teste abrangentes, o que tipicamente precede o lançamento mais amplo.

Como o JPEG XL supera todas as alternativas. E onde não supera

A história da eficiência de compressão é nuanceada e depende fortemente do tipo de conteúdo e da taxa de bits. No nível mais alto, o JPEG XL vence nas comparações mais importantes do mundo real.

Contra JPEG

Os ganhos são dramáticos. O JPEG XL alcança qualidade visualmente sem perdas em aproximadamente 1,2 bits por pixel onde o JPEG requer 2,4 bpp. Uma melhoria de 2:1. O benchmark do DebugBear de uma fotografia de 990 KB mostrou o JPEG XL com 472 KB (52% de economia), comparado ao WebP com 700 KB e AVIF com 507 KB. Os testes da Cloudinary com mais de 40.000 imagens descobriram que o JPEG XL no esforço 6 produziu arquivos 20% menores que AVIF enquanto codificava 2,5x mais rápido.

Contra AVIF

A comparação depende da taxa de bits. Em taxas de bits baixas abaixo de 0,4 bpp (compressão pesada), o AVIF supera o JPEG XL. Ele produz imagens mais suaves com menos artefatos. Em taxas de bits médias a altas (0,4 bpp e acima), onde a maioria da fotografia web se encontra, o JPEG XL consistentemente vence na preservação de detalhes e fidelidade. O próprio estudo de comparação AVIF do Google mostrou 9 de 13 métricas de qualidade favorecendo o JPEG XL em configurações práticas de velocidade do codificador. A diferença de velocidade de codificação é enorme: AVIF (via libaom) é uma ordem de magnitude mais lento que o JPEG XL em codificação de thread único. Nas configurações mais lentas do AVIF (~0,5 Mpx/s), ele iguala a densidade de compressão da segunda configuração mais rápida do JPEG XL a 52 Mpx/s. Uma diferença de velocidade de 100x.

Contra WebP

O JPEG XL vence decisivamente. O WebP é limitado a 8 bits de profundidade de cor, subamostragem de croma 4:2:0 no modo com perdas e uma resolução máxima de 16.383 x 16.383 pixels. O JPEG XL suporta até 32 bits por canal (inteiro ou ponto flutuante), resoluções excedendo 1 bilhão de pixels por lado e não tem restrição de subamostragem de croma.

O tipo de conteúdo importa

Para tipos específicos de conteúdo, os benchmarks do DebugBear revelaram um cenário mais misto. O AVIF venceu em logotipos (2 KB vs 6 KB do JXL) e imagens com transparência (18 KB vs 63 KB), enquanto o JPEG XL venceu em fotografias (472 KB vs 507 KB) e conteúdo animado onde alcançou 99% de compressão (14 KB de um GIF de 1,3 MB, versus 56 KB do AVIF). Esses resultados usaram as configurações padrão da Cloudinary, então representam saídas típicas em vez de otimizadas.

Comparação de recursos

Dois recursos que nenhum outro formato consegue igualar

Os recursos estrategicamente mais importantes do JPEG XL são a decodificação progressiva e a transcodificação sem perdas de JPEG. Nenhum concorrente oferece nenhum dos dois.

Decodificação progressiva

A decodificação progressiva muda fundamentalmente como as imagens carregam. Os arquivos JPEG XL são sempre pelo menos 8x8 progressivos; o frame DC (baixa frequência) é sempre codificado primeiro. Com apenas ~1% dos dados do arquivo baixados, uma pré-visualização utilizável da imagem completa aparece. Compare isso com o JPEG progressivo, que requer 10 a 15% para sua primeira varredura. Mais importante, o JPEG XL suporta progressão ordenada por saliência: modelos de aprendizado de máquina podem identificar as regiões visualmente mais importantes (rostos em retratos, detalhes de produtos em e-commerce) e codificar essas regiões para chegarem primeiro. O decodificador suaviza os limites entre regiões concluídas e em carregamento.

Isso cria uma linha do tempo de renderização diferente. O AVIF requer a imagem comprimida completa antes que a decodificação possa começar: o tempo total é igual ao tempo de download mais o tempo de decodificação, sequencialmente. O JPEG XL sobrepõe transferência e decodificação, então o usuário vê conteúdo significativo muito mais cedo. A Cloudinary observou que a renderização progressiva do JPEG XL elimina a necessidade de arquivos separados de Low Quality Image Placeholder (LQIP), removendo bytes redundantes inteiramente. No entanto, vale notar que a implementação atual do Safari não suporta decodificação progressiva, o que limita essa vantagem às futuras implementações do Chrome e Firefox.

Transcodificação sem perdas de JPEG

A transcodificação sem perdas de JPEG é o recurso oculto do JPEG XL. O formato pode copiar diretamente os coeficientes de bloco DCT do JPEG em seus próprios blocos VarDCT, melhorando apenas a codificação de entropia. O resultado: ~20% de redução média no tamanho do arquivo (intervalo: 13 a 22%) com o arquivo JPEG original reconstruível bit a bit a partir do arquivo JXL. Nenhum outro formato pode fazer isso. Transcodificar para WebP ou AVIF requer decodificar para pixels e recodificar, causando perda de geração. A API DICOM do Google Cloud Platform já usa essa capacidade para reduzir o tamanho de arquivos de imagens médicas em 20%.

Em escala web, se todos os JPEGs atuais fossem transcodificados sem perdas para JXL, a economia de largura de banda seria enorme. A comunidade JPEG XL estima que a economia de energia seria equivalente a alimentar ~487.000 residências nos EUA por uma hora por dia.

O que isso significa para os Core Web Vitals

O JPEG XL afeta cada métrica de Core Web Vital através de mecanismos diferentes, e a relação é mais nuanceada do que "arquivos menores = melhores pontuações".

LCP (Largest Contentful Paint)

O LCP se beneficia de dois efeitos compostos. Primeiro, tamanhos de arquivo menores reduzem a Resource Load Duration. A fase de download. Uma redução de 52% em relação ao JPEG significa que a imagem hero chega aproximadamente duas vezes mais rápido em conexões com largura de banda limitada. Segundo, o JPEG XL decodifica mais rápido que o AVIF, reduzindo o Element Render Delay. A decodificação complexa do AVIF, derivada de codec de vídeo, pode criar uma sobrecarga significativa de CPU em dispositivos móveis, onde um AVIF menor que baixa mais rápido pode ser parcialmente negado pelo tempo de decodificação mais longo. A velocidade de decodificação do JPEG XL de até 132 Mpx/s e a otimização SIMD minimizam esse gargalo. No entanto, o LCP é medido quando a imagem é totalmente renderizada, então a decodificação progressiva não melhora diretamente o timestamp do LCP. Ela melhora o desempenho percebido, o que importa para a experiência do usuário mesmo que não mova a métrica. Se o JPEG XL é o formato da sua imagem LCP, faça o preload para que o navegador a descubra o mais cedo possível.

CLS (Cumulative Layout Shift)

O CLS não se importa com formato. Todos os formatos se beneficiam igualmente de atributos explícitos de largura e altura. O JPEG XL codifica informações de dimensão nos cabeçalhos iniciais, o que poderia teoricamente ajudar os navegadores a alocar espaço mais rápido, mas o impacto prático é negligível comparado a simplesmente definir dimensões no HTML.

INP (Interaction to Next Paint)

O INP pode ser afetado pela decodificação pesada de imagens no thread principal. A decodificação mais rápida do JPEG XL e a otimização SIMD significam menos bloqueio do thread principal que o AVIF, embora ambos os formatos sejam tipicamente decodificados fora do thread principal em navegadores modernos.

Impacto no mundo real

De acordo com o Web Almanac 2025, o JPEG ainda representa 57% das imagens LCP tanto em dispositivos móveis quanto desktop. O WebP cresceu para 11%, um aumento de 4 pontos percentuais em relação a 2024. O AVIF está em apenas 0,7%. O JPEG XL ainda nem é medido. A página web mediana carrega 19 imagens em dispositivos móveis pesando 911 KB no total. Converter essas de JPEG para JPEG XL economizaria aproximadamente 450 a 550 KB por página. No peso mediano de imagens desktop de 1.058 KB, a economia se aproxima de 500 a 630 KB.

Entre os sites monitorados pelo CoreDash, páginas servindo imagens em formatos modernos (AVIF ou WebP) mostram 81% de taxas boas de LCP, comparado a 64% para páginas que ainda dependem exclusivamente de JPEG. À medida que o JPEG XL alcança suporte mais amplo de navegadores, a diferença deve aumentar ainda mais. Monitorar seus dados de Real User Monitoring após habilitar a entrega de JXL dirá exatamente quanto os usuários reais se beneficiam.

Servindo JPEG XL hoje com fallbacks adequados

A implementação requer uma estratégia em camadas: o elemento <picture> para imagens HTML, negociação de conteúdo do lado do servidor para CSS e imagens referenciadas dinamicamente, e automação de CDN onde disponível.

O elemento picture

O elemento <picture> fornece a abordagem mais limpa do lado do cliente. Os navegadores avaliam os elementos <source> de cima para baixo e usam o primeiro formato suportado:

<picture>
  <source srcset="hero.jxl" type="image/jxl">
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Description" width="1200" height="800"
       loading="lazy" decoding="async">
</picture>

Se esta imagem é sua hero e o provável elemento LCP, remova loading="lazy" e defina seu fetchpriority como high. Nunca aplique lazy load na sua imagem LCP.

Para imagens responsivas, cada source precisa de seu próprio srcset com descritores de largura. Criando uma explosão combinatória de mais de 12 variantes por imagem (3 ou 4 formatos x 3 ou 4 tamanhos). É aqui que a automação de CDN se torna essencial.

Negociação de conteúdo do lado do servidor

A negociação de conteúdo do lado do servidor inspeciona o cabeçalho Accept. O Safari 17+ envia image/jxl em seu cabeçalho Accept. A configuração do Nginx mapeia isso para extensões de arquivo:

map $http_accept $img_ext {
    ~image/jxl   '.jxl';
    ~image/avif  '.avif';
    ~image/webp  '.webp';
    default      '';
}

O detalhe crítico: sempre inclua Vary: Accept no cabeçalho de resposta para que CDNs e caches de proxy armazenem variantes separadas por formato. Sem isso, uma resposta JXL em cache será servida para navegadores que não conseguem decodificá-la.

Suporte de CDN

O suporte de CDN é desigual. A Cloudinary oferece suporte completo a JPEG XL através de seu parâmetro f_auto. Sem surpresa, dado que a Cloudinary co-criou o formato e já entrega aproximadamente 1 bilhão de imagens JPEG XL por dia. O Image Optimizer da Fastly adicionou suporte completo a JPEG XL em julho de 2024, usando esforço de codificação 3 com 4 threads e alegando ~60% de economia sobre JPEG. A Cloudflare, apesar da forte demanda da comunidade, não suporta a conversão para JPEG XL em seu produto Image Resizing. Ela pode cachear variantes JXL do seu servidor de origem via Vary: Accept, mas não pode gerá-las. Se você usa Cloudflare, confira nosso guia para configurar a Cloudflare para Core Web Vitals para as configurações que ajudam. AWS CloudFront, Akamai e Azure não possuem suporte nativo a JPEG XL.

Ferramentas

As ferramentas para gerar arquivos JPEG XL centram-se no cjxl da implementação de referência libjxl. Parâmetros chave: -d para distância (0 = sem perdas, 1,0 a 2,0 para qualidade web com perdas), -e para esforço (1 a 9, padrão 7), e -p para codificação progressiva. Para entradas JPEG, cjxl input.jpg output.jxl realiza transcodificação sem perdas por padrão. O caminho de migração mais simples possível. ImageMagick, libvips (desde 8.11) e Photoshop v25 também suportam JXL. No entanto, sharp (a biblioteca de imagens Node.js que alimenta o Next.js) tem suporte experimental a JXL desde v0.31.3, mas os binários pré-compilados distribuídos via npm não incluem o codec JXL. Você precisaria compilar o libvips por conta própria com suporte a libjxl, e o mantenedor encerrou o pedido para binários pré-compilados com JXL. Isso significa que o Next.js não tem suporte prático a JPEG XL pronto para uso. O suporte do WordPress core é rastreado como ticket #52788, mas o verdadeiro bloqueador é que a extensão GD do PHP não suporta JPEG XL. O PHP 8.5 (novembro de 2025) ainda não tem suporte GD para JXL.

A decisão de Halloween e sua reversão de três anos

A história política do JPEG XL no Chrome é um estudo de caso sobre o poder dos fornecedores de navegadores sobre os padrões web. Entendê-la importa porque revela as forças que moldam quais tecnologias chegam aos usuários.

Em 31 de outubro de 2022, no que rapidamente foi apelidado de "decisão de Halloween", Jim Bankoski da equipe Chrome do Google anunciou a remoção do suporte experimental ao JPEG XL. As razões declaradas foram quatro: flags experimentais não devem permanecer indefinidamente; interesse insuficiente do ecossistema; benefícios incrementais insuficientes sobre os formatos existentes; e custo de manutenção. Bankoski sugeriu o WebAssembly como "um ótimo caminho a seguir" para quem quisesse JPEG XL no Chrome.

A reação foi imediata e sustentada. A issue no Chromium se tornou a segunda mais estrelada em toda a história do projeto, com mais de 1.000 votos positivos e comentários de representantes da Intel, Adobe, Meta, Shopify, The Guardian, Flickr e da Krita Foundation. Jon Sneyers, co-criador do JPEG XL na Cloudinary, publicou uma refutação técnica detalhada ("The Case for JPEG XL") mostrando que os testes de comparação publicados pelo Google usaram implementações JPEG XL com bugs e métricas enviesadas a favor do AVIF. A Free Software Foundation chamou a decisão do Google de evidência de que o Google Chrome se tornou o árbitro dos padrões web e acusou a empresa de agir em seus próprios interesses. Já que o AVIF deriva do AV1, desenvolvido pela Alliance for Open Media que o Google co-fundou.

A ironia não passou despercebida pelos observadores: o próprio Google co-criou o JPEG XL através de seu projeto PIK, tornando a decisão de removê-lo do Chrome ainda mais confusa. Quando o JPEG XL foi proposto para o Interop 2024, recebeu 646 reações da comunidade. 4,5x a segunda proposta mais votada. E foi rejeitado com apenas "falta de consenso" como explicação.

O que finalmente reverteu a decisão foi o impulso do ecossistema que tornou a ausência do Chrome insustentável. A Apple lançando o Safari 17 com suporte a JPEG XL em setembro de 2023 foi a primeira grande ruptura. A Mozilla mudando de "negativa" para "neutra" e depois para ativamente disposta a implementar (com um decodificador Rust) adicionou pressão. O anúncio da PDF Association do JPEG XL como formato HDR preferido para PDF em outubro de 2025 pode ter sido o ponto de virada. O visualizador de PDF integrado do Chrome precisaria de suporte a JXL para permanecer em conformidade. Em 21 de novembro de 2025, Rick Byers (Chrome Architecture Tech Lead) publicou a reversão, dando boas-vindas a contribuições para integrar um decodificador JPEG XL de alto desempenho e seguro em memória no Chromium. Em janeiro de 2026, o decodificador baseado em Rust jxl-rs foi mesclado, e o Chrome 145 o lançou atrás de uma flag em fevereiro de 2026.

Conclusão: armazene fontes de qualidade, converta sob demanda

O JPEG XL é tecnicamente o melhor formato de imagem de uso geral disponível. Melhor compressão que o AVIF em velocidades práticas de codificação, decodificação progressiva que nenhum concorrente oferece, e transcodificação sem perdas de JPEG que proporciona uma economia instantânea de 20% sem perda de qualidade. Os obstáculos políticos que bloquearam sua adoção por três anos estão se dissolvendo: o Chrome tem código na árvore, o Firefox está integrando ativamente o mesmo decodificador Rust, e o Safari já oferece suporte desde 2023.

O caminho prático é armazenar o material fonte da mais alta qualidade possível e deixar seu pipeline de entrega lidar com a conversão de formato. Mantenha PNGs sem perdas ou JPEGs master de alta qualidade como seus originais. Use uma CDN com negociação automática de formato: o f_auto da Cloudinary, o Fastly Image Optimizer ou o Cloudflare Polish inspecionarão o cabeçalho Accept do navegador e servirão JXL, AVIF, WebP ou JPEG sem que você precise gerar uma única variante previamente. Se você hospeda por conta própria, configure a conversão sob demanda com libvips ou ImageMagick atrás de um cache do lado do servidor, convertendo uma vez por formato na primeira requisição em vez de gerar quatro variantes por imagem antecipadamente. A transcodificação sem perdas do JPEG XL se encaixa perfeitamente neste modelo: seus JPEGs existentes são a fonte, e convertê-los para JXL é efetivamente conversão sob demanda sem perda de qualidade. A questão em aberto não é se o JPEG XL alcançará amplo suporte de navegadores, mas quando o Chrome mudará a flag de desativado para ativado por padrão. E a única resposta honesta é que nenhum cronograma foi anunciado. O exílio de três anos do formato do Chrome deve temperar o entusiasmo com pragmatismo: sirva-o onde suportado, faça fallback graciosamente em outros lugares, e deixe a CDN ou o pipeline de conversão cuidar do resto.