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

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, é fornecido com um decodificador JPEG XL. Ainda por trás de uma flag, mas funcionalmente presente na base de código pela primeira vez desde sua remoção controversa no final de 2022. Isso é importante 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, 10 a 15% melhor compactação que o AVIF em velocidades de codificação equivalentes e o único formato moderno com decodificação progressiva real. Para profissionais de desempenho na web, a trajetória do formato, de padrão ISO ao exílio do Chrome até a ressurreição, representa tanto uma oportunidade técnica quanto um conto de advertência sobre o poder dos fornecedores de navegadores sobre a plataforma da web.

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

O suporte nos 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.

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 à estrutura de imagem em nível de sistema operacional, o que significa que funciona em qualquer lugar onde 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 enfraquece a proposta de valor total do formato nos dispositivos da Apple.

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

Para testar 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á forneça imagens em 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 por trás da flag image.jxl.enabled. De forma crítica, 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". O decodificador jxl-rs em Rust foi introduzido no Firefox Nightly (visando o Firefox 149), mas restam seis bloqueadores antes que possa ser lançado na versão estável: suporte a perfil 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 o suporte estável.

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

Interop 2026 incluiu o JPEG XL como uma área de investigação (não uma área de foco total), com Apple, Google, Microsoft e Mozilla todos participando. Isso sinaliza a intenção conjunta dos fornecedores de criar conjuntos de testes abrangentes, o que normalmente precede um lançamento mais amplo.

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

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

Contra o JPEG

Os ganhos são dramáticos. O JPEG XL atinge uma qualidade visualmente sem perdas a aproximadamente 1,2 bits por pixel, onde o JPEG exige 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 (economia de 52%), em comparação com WebP com 700 KB e AVIF com 507 KB. O teste da Cloudinary de mais de 40.000 imagens descobriu que o JPEG XL no esforço 6 produziu arquivos 20% menores que o AVIF enquanto codificava 2,5x mais rápido.

Contra o AVIF

A comparação depende da taxa de bits. Em taxas de bits baixas, inferiores a 0,4 bpp (compactação pesada), o AVIF supera o JPEG XL. Ele produz imagens mais suaves e com menos artefatos. Em taxas de bits médias a altas (0,4 bpp e acima), onde reside a maior parte da fotografia 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 que o JPEG XL em codificação single-threaded. 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 decisivamente. O WebP é limitado a uma profundidade de cor de 8 bits, 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 superiores a 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 cenário mais misto. O AVIF venceu em logotipos (2 KB contra 6 KB do JXL) e imagens transparentes (18 KB contra 63 KB), enquanto o JPEG XL venceu em fotografias (472 KB contra 507 KB) e em 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 ambos.

Decodificação progressiva

A decodificação progressiva muda fundamentalmente a forma como as imagens são carregadas. 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 utilizável da imagem completa aparece. Compare isso com o JPEG progressivo, que requer de 10 a 15% para sua primeira varredura. Mais importante, o JPEG XL suporta a 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 as fronteiras 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 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, de modo que o usuário vê o conteúdo significativo muito mais cedo. A Cloudinary observou que a renderização progressiva do JPEG XL elimina a necessidade de arquivos Low Quality Image Placeholder (LQIP) separados, removendo totalmente os bytes redundantes. No entanto, vale a pena notar que a implementação atual do Safari não oferece suporte à decodificação progressiva, o que limita essa vantagem a futuras implementações no Chrome e 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 por entropia. O resultado: ~20% de redução média no tamanho do arquivo (variação: 13 a 22%) com o arquivo JPEG original sendo reconstruível bit a bit a partir do arquivo JXL. Nenhum outro formato pode fazer isso. Transcodificar para WebP ou AVIF exige a decodificação em pixels e a recodificação, causando perda de geração. A DICOM API do Google Cloud Platform já utiliza essa capacidade para reduzir os tamanhos de arquivo 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 a economia de energia equivalente ao fornecimento de energia para cerca de 487.000 lares nos EUA durante uma hora por dia.

O que isso significa para os Core Web Vitals

O JPEG XL afeta cada métrica dos Core Web Vitals por meio 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 o Resource Load Duration. A fase de download. Uma redução de 52% em relação ao JPEG significa que a imagem de herói chega aproximadamente duas vezes mais rápido em conexões com largura de banda restrita. Segundo, o JPEG XL decodifica mais rápido que o AVIF, reduzindo o Element Render Delay. A complexa decodificação derivada de codec de vídeo do AVIF pode criar uma sobrecarga de CPU significativa em dispositivos móveis, onde um AVIF menor que baixa mais rápido pode ser parcialmente anulado 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, então a decodificação progressiva não melhora diretamente o timestamp do LCP. Ela melhora a percepção de desempenho, o que é importante para a user experience mesmo que não mova a métrica. Se o JPEG XL for 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 o formato. Todos os formatos se beneficiam igualmente dos atributos explícitos de largura e altura. O JPEG XL de fato codifica as informações de dimensão nos cabeçalhos iniciais, o que, teoricamente, poderia ajudar os navegadores a alocar espaço mais rápido, 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 pela 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 na thread principal do que o AVIF, embora ambos os formatos normalmente sejam decodificados fora da thread principal nos navegadores modernos.

Impacto no mundo real

De acordo com o Web Almanac de 2025, o JPEG ainda responde por 57% das imagens LCP tanto no celular quanto no 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 nem sequer é medido ainda. A página da web mediana carrega 19 imagens no celular pesando 911 KB no total. A conversão destas de JPEG para JPEG XL economizaria cerca de 450 a 550 KB por página. No peso mediano das imagens em desktops de 1.058 KB, as economias se aproximam de 500 a 630 KB.

Em sites monitorados pelo CoreDash, páginas que servem imagens em formatos modernos (AVIF ou WebP) apresentam taxas de bom LCP de 81%, em comparação com 64% das páginas que ainda dependem exclusivamente do JPEG. À medida que o JPEG XL alcança suporte mais amplo nos navegadores, a lacuna deve aumentar ainda mais. Monitorar seus dados de Real User Monitoring depois de habilitar a entrega em JXL lhe dirá exatamente o quanto os usuários reais se beneficiam.

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 via CDN quando disponível.

O elemento picture

O elemento <picture> fornece a abordagem mais limpa no 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 for o seu hero e o provável elemento do LCP, remova loading="lazy" e defina sua fetchpriority para high. Nunca utilize lazy load na sua imagem LCP.

Para imagens responsivas, cada source precisa do seu próprio srcset com os 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 por 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 as 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 os CDNs e os caches de proxy armazenem variantes separadas por formato. Sem isso, uma resposta em JXL armazenada em cache será servida para navegadores que não conseguem decodificá-la.

Suporte a CDN

O suporte a CDN é irregular. A Cloudinary oferece suporte total ao JPEG XL através do seu parâmetro f_auto. O que não surpreende, dado que a Cloudinary cocriou o formato e já entrega aproximadamente 1 bilhão de imagens JPEG XL por dia. O Fastly's Image Optimizer adicionou suporte completo ao JPEG XL em julho de 2024, usando o esforço de codificação 3 com 4 threads e reivindicando ~60% de economia sobre o JPEG. A Cloudflare, apesar da forte demanda da comunidade, não suporta a conversão de JPEG XL em seu produto de Image Resizing. Ela pode armazenar em cache variantes de JXL da sua origem por meio de Vary: Accept, mas não pode gerá-las. Se você usa Cloudflare, verifique nosso guia de como configurar o Cloudflare para os Core Web Vitals para descobrir quais configurações realmente ajudam. 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. Principais parâmetros: -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 as entradas em JPEG, cjxl input.jpg output.jxl executa 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 o JXL. No entanto, o sharp (a biblioteca de imagens em Node.js que impulsiona o Next.js) possui suporte experimental a JXL desde a v0.31.3, mas os binários pré-compilados distribuídos via npm não incluem o codec JXL. Você precisaria compilar o libvips você mesmo com o suporte libjxl, e o mantenedor fechou o pedido para binários JXL pré-compilados. Isso significa que o Next.js não tem suporte prático ao JPEG XL pronto para uso. O suporte principal do WordPress é rastreado como o ticket #52788, mas o verdadeiro bloqueio é que a extensão GD do PHP não suporta o JPEG XL. O PHP 8.5 (novembro de 2025) ainda carece de suporte a GD para JXL.

A decisão do Halloween e a 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 em relação aos padrões da web. Entender isso é importante porque revela as forças que moldam quais tecnologias chegam aos usuários.

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

A reação negativa foi imediata e constante. A issue do Chromium tornou-se a segunda mais favoritada em toda a história do projeto, com mais de 1.000 upvotes e comentários de representantes da Intel, Adobe, Meta, Shopify, The Guardian, Flickr e da Krita Foundation. Jon Sneyers, cocriador do JPEG XL na Cloudinary, publicou uma detalhada refutação técnica ("The Case for JPEG XL") mostrando que os testes de comparação publicados pelo Google usavam implementações do JPEG XL com bugs e métricas tendenciosas a favor do AVIF. A Free Software Foundation classificou a decisão do Google como uma evidência de que o Google Chrome havia se tornado o árbitro dos padrões da web e acusou a empresa de agir em benefício próprio. Já que o AVIF deriva do AV1, desenvolvido pela Alliance for Open Media que o Google cofundou.

A ironia não passou despercebida pelos observadores: o próprio Google cocriou o JPEG XL através de seu projeto PIK, tornando a decisão de eliminá-lo do Chrome ainda mais confusa. Quando o JPEG XL foi proposto para o Interop 2024, ele recebeu 646 reações da comunidade. 4,5x a proposta do segundo colocado. E foi rejeitada com apenas a "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 ao JPEG XL em setembro de 2023 foi a primeira grande ruptura. A Mozilla mudando de "negativa" para "neutra" e depois para a disposição ativa em implementar (com um decodificador em 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 do suporte ao JXL para se manter em conformidade. Em 21 de novembro de 2025, Rick Byers (Líder Técnico de Arquitetura do Chrome) postou a reversão, recebendo contribuições para integrar um decodificador JPEG XL de alta performance e com segurança de memória no Chromium. Em janeiro de 2026, o decodificador jxl-rs baseado em Rust foi mesclado, e o Chrome 145 o enviou atrás de uma flag em fevereiro de 2026.

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

Tecnicamente, o JPEG XL é o melhor formato de imagem de uso geral disponível. Melhor compactação que o AVIF em velocidades práticas de codificação, decodificação progressiva que nenhum concorrente oferece e transcodificação JPEG sem perdas que fornece 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 o código na base, o Firefox está integrando ativamente o mesmo decodificador em Rust, e o Safari entrega esse suporte desde 2023.

O caminho prático a seguir é armazenar o material de origem de maior qualidade que você puder e deixar que seu pipeline de entrega lide com a conversão de formato. Mantenha os PNGs sem perdas ou os JPEGs mestres de alta qualidade como originais. Use um CDN com negociação de formato automática: o f_auto da Cloudinary, o Fastly Image Optimizer ou o Cloudflare Polish vão inspecionar o cabeçalho Accept do navegador e servirão em JXL, AVIF, WebP ou JPEG sem que você tenha que gerar uma única variante de antemão. Se você utiliza hospedagem própria, configure a conversão sob demanda com o libvips ou o ImageMagick atrás de um cache no lado do servidor, convertendo uma vez por formato na primeira solicitação em vez de gerar em lote quatro variantes por imagem antecipadamente. A transcodificação sem perdas do JPEG XL se ajusta perfeitamente a esse modelo: seus JPEGs existentes são a origem, e convertê-los para JXL é efetivamente uma conversão sob demanda com zero perda de qualidade. A questão aberta não é se o JPEG XL alcançará amplo suporte nos navegadores, mas sim quando o Chrome mudará a flag de desligada para ativada por padrão. E a única resposta honesta é que nenhum cronograma foi anunciado. O exílio de três anos do formato em relação ao Chrome deve moderar o entusiasmo com o pragmatismo: sirva-o onde for suportado, faça o fallback suavemente em outros lugares e deixe o CDN ou o pipeline de conversão lidar com o resto.