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

O JPEG XL finalmente está 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 na base de código pela primeira vez desde sua remoção polêmica no final de 2022. Isso importa porque o JPEG XL é demonstravelmente superior a todos os formatos de imagem da web estabelecidos na maioria das dimensões técnicas: 50 a 60% menor que o JPEG, compactação 10 a 15% melhor que o 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 conto de advertência sobre o poder dos fornecedores de navegadores sobre a plataforma web.

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

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

O Safari 17+ (lançado em setembro de 2023) fornece decodificação nativa de JPEG XL no macOS Sonoma, iOS 17, iPadOS 17, watchOS e visionOS. A implementação da Apple delega a decodificação para a estrutura de imagem no nível do sistema operacional, o que significa que funciona em todos os lugares em que o Safari é executado. No entanto, o suporte do Safari é explicitamente parcial: sem suporte a animação e sem decodificação progressiva. Duas das características mais distintas do JPEG XL. Essa é uma limitação significativa que reduz a proposta de valor total do formato em dispositivos Apple.

O Chrome 145 (fevereiro de 2026) reintroduz o JPEG XL através de um decodificador em Rust puro chamado jxl-rs, substituindo a implementação anterior em C++ do libjxl. O decodificador está restrito pela flag chrome://flags/#enable-jxl-image-format e não é ativado por padrão. O Google estabeleceu condições claras para a ativação padrão: um compromisso com a manutenção de longo prazo e o cumprimento dos critérios padrão de lançamento. O decodificador em Rust atualmente atinge 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. Os recursos funcionais confirmados incluem perfis de cores ICC, animações, alfa/transparência, ampla gama de cores (Display P3) e HDR (PQ/HLG).

O Firefox continua sendo o mais atrasado. O formato está disponível apenas no Firefox Nightly através da flag image.jxl.enabled. Criticamente, o código do decodificador não é compilado em builds estáveis de forma alguma, então a flag não faz nada no Firefox de lançamento. A posição da Mozilla mudou de "negativa" para "neutra", com trabalho ativo (Bug 1986393) para integrar o mesmo decodificador jxl-rs em Rust. Não existe um cronograma para o suporte estável.

O 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 ao JPEG XL. As notas de lançamento do Edge 145 não fazem menção a ele.

A Interop 2026 incluiu o JPEG XL como uma área de investigação (não uma área de foco total), com a participação da Apple, Google, Microsoft e Mozilla. Isso sinaliza a intenção entre os fornecedores de criar conjuntos de testes abrangentes, o que normalmente 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 da compactação tem nuances e depende muito do tipo de conteúdo e da taxa de bits. No nível mais alto, o JPEG XL vence as comparações do mundo real mais importantes.

Contra o JPEG

Os ganhos são dramáticos. O JPEG XL atinge qualidade visualmente sem perdas com aproximadamente 1,2 bits por pixel onde o JPEG requer 2,4 bpp. Uma melhoria de 2:1. O benchmark da DebugBear de uma fotografia de 990 KB mostrou o JPEG XL com 472 KB (52% de economia), comparado ao WebP com 700 KB e ao 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 o AVIF enquanto codificava 2,5 vezes mais rápido.

Contra o AVIF

A comparação depende da taxa de bits. Em taxas de bits baixas, abaixo de 0,4 bpp (compactação pesada), o AVIF supera o JPEG XL. Ele produz imagens mais suaves com menos artefatos. Nas taxas de bits médias a altas (0,4 bpp e acima), onde reside a maior parte da fotografia da web, o JPEG XL vence consistentemente na preservação de detalhes e fidelidade. O próprio estudo de comparação de 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 lacuna na velocidade de codificação é enorme: o AVIF (via libaom) é uma ordem de magnitude mais lento do 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 compactação da segunda configuração mais rápida do JPEG XL a 52 Mpx/s. Uma diferença de velocidade de 100x.

Contra o WebP

O JPEG XL vence de forma decisiva. 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 que excedem 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 da DebugBear revelaram um quadro mais misto. O AVIF venceu em logotipos (2 KB contra 6 KB do JXL) e imagens com transparência (18 KB contra 63 KB), enquanto o JPEG XL venceu em fotografias (472 KB contra 507 KB) e conteúdo animado, onde alcançou 99% de compactação (14 KB de um GIF de 1,3 MB, contra 56 KB do AVIF). Esses resultados usaram as configurações padrão da Cloudinary, portanto, 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 JPEG sem perdas. Nenhum concorrente oferece nenhum dos dois.

Decodificação progressiva

A decodificação progressiva muda fundamentalmente como as imagens são carregadas. Os arquivos JPEG XL são sempre pelo menos 8x8 progressivos; o quadro DC (baixa frequência) é sempre codificado primeiro. Com apenas ~1% dos dados do arquivo baixados, uma visualização útil de toda a imagem aparece. Compare isso com o JPEG progressivo, que requer 10 a 15% para sua primeira varredura. Mais importante ainda, 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 as regiões concluídas e as que ainda estão carregando.

Isso cria uma linha do tempo de renderização diferente. O AVIF requer a imagem compactada inteira 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, para que o usuário veja um 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 totalmente os bytes redundantes. No entanto, vale a pena notar que a implementação atual do Safari não suporta a decodificação progressiva, o que limita essa vantagem a futuras implementações do Chrome e do Firefox.

Transcodificação JPEG sem perdas

A transcodificação JPEG sem perdas é 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 (variando de 13 a 22%) com o arquivo JPEG original reconstruível bit a bit a partir do arquivo JXL. Nenhum outro formato consegue fazer isso. A transcodificação para WebP ou AVIF requer a decodificação em pixels e nova codificação, causando perda de geração. A API DICOM da Google Cloud Platform já utiliza esse recurso para reduzir o tamanho de arquivos de imagens médicas em 20%.

Em escala da 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 uma economia de energia equivalente a abastecer ~487.000 lares nos EUA por uma hora por dia.

O que isso significa para os Core Web Vitals

O JPEG XL afeta cada métrica do Core Web Vitals através de diferentes mecanismos, e a relação tem mais nuances 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 Duração de Carregamento de Recurso (Resource Load Duration). A fase de download. Uma redução de 52% em relação ao JPEG significa que a hero image chega aproximadamente duas vezes mais rápido em conexões com largura de banda restrita. Em segundo lugar, o JPEG XL é decodificado mais rápido que o AVIF, reduzindo o Atraso na Renderização do Elemento (Element Render Delay). A decodificação complexa do AVIF, derivada de codec de vídeo, pode criar uma sobrecarga de CPU significativa em dispositivos móveis, onde um AVIF menor que faz download mais rápido pode ser parcialmente negado por um 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 está totalmente renderizada, portanto, a decodificação progressiva não melhora diretamente o timestamp do LCP. Ela melhora a percepção de desempenho, o que é importante para a experiência do usuário, mesmo que não mova a métrica.

CLS (Cumulative Layout Shift)

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

INP (Interaction to Next Paint)

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

Impacto no mundo real

A página da web mediana em 2025 carrega 19 imagens no celular pesando 911 KB no total (HTTP Archive Web Almanac 2025). Converter estas de JPEG para JPEG XL economizaria cerca de 450 a 550 KB por página. Uma melhoria substancial para usuários em redes restritas. Com um peso de imagem mediano no desktop de 1.058 KB, a economia se aproxima de 500 a 630 KB.

Servindo o 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 no 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>

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 da CDN se torna essencial.

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

A negociação de conteúdo no 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 as 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 total ao JPEG XL através do seu parâmetro f_auto. Não é surpreendente, já 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 total ao JPEG XL em julho de 2024, usando o esforço de codificação 3 com 4 threads e reivindicando uma economia de ~60% sobre o JPEG. A Cloudflare, apesar da forte demanda da comunidade, não suporta a conversão de JPEG XL em seu produto Image Resizing. Ela pode armazenar em cache as variantes JXL da sua origem através do Vary: Accept, mas não pode gerá-las. A AWS CloudFront, Akamai e Azure não têm suporte nativo a JPEG XL.

Ferramentas

As ferramentas para gerar arquivos JPEG XL concentram-se no cjxl da implementação de referência libjxl. Parâmetros principais: -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 a transcodificação sem perdas por padrão. O caminho de migração mais simples possível. ImageMagick, libvips (desde a versão 8.11) e Photoshop v25 também suportam JXL. No entanto, o sharp (a biblioteca de imagens Node.js que impulsiona o Next.js) ainda não expõe a saída JXL, o que significa que o Next.js não tem suporte nativo a JPEG XL. O suporte principal do WordPress é rastreado como o tíquete #52788, marcado como "maybelater".

A decisão de Halloween e a 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 da web. Entendê-la é importante porque revela as forças que moldam quais tecnologias chegam aos usuários.

Em 31 de outubro de 2022. Apelidada de "A decisão de Halloween." Jim Bankoski, da equipe do Google Chrome, anunciou a remoção do suporte experimental ao JPEG XL. Os motivos alegados foram quatro: flags experimentais não devem permanecer indefinidamente; interesse insuficiente do ecossistema; benefícios incrementais insuficientes em relação aos formatos existentes; e carga de manutenção. Bankoski sugeriu o WebAssembly como "um ótimo caminho a seguir" para aqueles que queriam o JPEG XL no Chrome.

A reação foi imediata e sustentada. O problema no Chromium tornou-se o segundo com mais estrelas 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 a Fundação Krita. Jon Sneyers, o 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 usavam implementações com bugs do JPEG XL e métricas enviesadas em favor do AVIF. A Free Software Foundation chamou a decisão do Google de evidência de que o Google Chrome havia se tornado o árbitro dos padrões da web e acusou a empresa de agir em prol de seus próprios interesses. Uma vez 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 do seu projeto PIK, tornando a decisão de eliminá-lo do Chrome ainda mais confusa. Quando o JPEG XL foi proposto para a Interop 2024, recebeu 646 reações da comunidade. 4,5x mais que a proposta do segundo lugar. E foi rejeitada com apenas uma "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. A PDF Association anunciando o JPEG XL como o formato HDR preferido para PDF em outubro de 2025 pode ter sido o ponto de virada. O visualizador de PDF embutido no Chrome precisaria de suporte a JXL para permanecer em conformidade. Em 21 de novembro de 2025, Rick Byers (Líder Técnico de Arquitetura do Chrome) postou a reversão, acolhendo contribuições para integrar um decodificador JPEG XL com bom desempenho e segurança de memória no Chromium. Até janeiro de 2026, o decodificador jxl-rs baseado em Rust foi mesclado, e o Chrome 145 o lançou atrás de uma flag em fevereiro de 2026.

Conclusão: prepare-se agora, implante incrementalmente

O JPEG XL é tecnicamente o melhor formato de imagem de uso geral disponível. Compactação melhor que a do AVIF em velocidades práticas de codificação, decodificação progressiva que nenhum concorrente oferece e transcodificação JPEG sem perdas que proporciona uma economia instantânea de 20% com zero 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 em Rust e o Safari lançou o suporte desde 2023.

O caminho prático a seguir para as equipes de desempenho na web é claro. Comece a gerar variantes JXL agora. A transcodificação JPEG sem perdas via cjxl é trivialmente automatizável e fornece economia imediata de 20% para os ~12% de usuários no Safari. Use os elementos <picture> ou a negociação de conteúdo com os cabeçalhos Vary: Accept para servir JXL junto com os fallbacks AVIF, WebP e JPEG. Se a sua CDN for Cloudinary ou Fastly, ative a entrega automática de JXL hoje mesmo. A questão em aberto não é se o JPEG XL alcançará amplo suporte dos navegadores, mas quando o Chrome mudará a flag de desligada para ligada por padrão. E a única resposta honesta é que nenhum cronograma foi anunciado. O exílio de três anos do formato no Chrome deve temperar o entusiasmo com pragmatismo: sirva-o onde houver suporte, faça fallback graciosamente em outros lugares e mantenha o pipeline pronto para o momento em que o suporte universal chegar.