O Formato é a Decisão que Vem Antes da Compressão

Na lição anterior, estabelecemos que imagens são o recurso mais pesado na maioria das páginas, que dimensionar corretamente importa mais do que apenas a compressão, e que a otimização de imagens abrange seis problemas distintos. Esta lição foca no primeiro que você precisa resolver: em qual formato esta imagem deve estar?

A escolha do formato está no topo de tudo o mais. Você pode comprimir um JPEG até um tamanho razoável, mas se ele deveria ter sido um WebP ou um SVG desde o início, você já aceitou uma penalidade que nenhum controle de qualidade pode recuperar. Tomar essa decisão corretamente antes de abrir qualquer ferramenta é o que separa um pipeline de imagens eficiente de um que comprime a coisa errada de forma eficiente.

Dois Tipos Fundamentalmente Diferentes de Imagens

A primeira pergunta a fazer sobre qualquer imagem não é "quão comprimida ela deve ser?" É: que tipo de dado esta imagem representa? A resposta determina se você deve trabalhar com um formato vetorial ou um formato raster — e esses dois são coisas fundamentalmente diferentes.

Imagens Vetoriais (SVG)

Uma imagem vetorial é um conjunto de instruções matemáticas: desenhe um círculo aqui, preencha este caminho com esta cor, escale esta forma para caber em seu contêiner. SVG é o formato vetorial dominante na web, e vale a pena realmente assimilar o que isso significa: um arquivo SVG é código XML. Não uma imagem no sentido tradicional, mas um documento de texto que descreve como desenhar uma imagem.

Por ser texto, o SVG comprime tão eficientemente quanto qualquer arquivo JavaScript ou HTML. Ele pode ser incorporado diretamente na sua marcação. E por ser matemático em vez de baseado em pixels, ele escala para qualquer tamanho sem qualquer alteração nos dados subjacentes. Um logo em 20px e o mesmo logo em 2000px usam exatamente o mesmo arquivo, com exatamente o mesmo tamanho de arquivo.

Um passo importante ao trabalhar com SVGs exportados de ferramentas como Figma, Illustrator ou Affinity Designer é executá-los pelo SVGO ou pelo SVGOMG, que é alimentado pelo SVGO.

Ferramentas de design incorporam quantidades significativas de metadados do editor: nomes de camadas, definições não utilizadas, dados de caminho redundantes de alças bezier que se cancelam. O SVGO ou SVGOMG remove tudo isso. É comum ver os tamanhos de arquivo caírem de 40 a 60 por cento sem nenhuma alteração visível na saída renderizada.

Logos, ícones, ilustrações, gráficos, diagramas etc. Em geral, qualquer coisa cujo conteúdo é definido por formas, caminhos e preenchimentos. Se você está servindo um PNG raster do logo da sua empresa, você está incorrendo em um custo real que o SVG eliminaria completamente.

Pode haver algumas exceções, como bandeiras de estados com formas complexas que deveriam ser servidas como imagens raster, mas em geral o SVG é a escolha certa para qualquer coisa que não seja uma fotografia ou textura fotorrealista.

Isso é tudo sobre SVG e formatos vetoriais, pois esta série se concentrará nos formatos raster, que são os mais comuns e os mais frequentemente mal gerenciados.

Imagens Raster (JPEG, PNG, WebP, AVIF)

Os formatos raster funcionam de maneira completamente diferente. Uma imagem raster é uma grade fixa de pixels, e cada pixel armazena informações de cor. Uma fotografia de 2000 por 1000 pixels é sempre 2000 por 1000 pixels. Se você a ampliar, o navegador inventa os pixels extras por meio de interpolação, o que degrada a qualidade. Se você a reduzir, está baixando muito mais pixels do que a tela exibirá.

Essa natureza de resolução fixa é o que torna as imagens raster simultaneamente o formato mais comum na web e o mais frequentemente mal gerenciado. Fotografia, imagens de produtos e qualquer coisa com gradientes de cores complexos ou textura fotorrealista pertence a um formato raster. A questão é: qual formato raster?

É aí que começa a decisão de engenharia real.

O Duelo de Formatos: WebP, AVIF e Quando Escolher Qual

O JPEG tem sido o formato padrão para conteúdo fotográfico na web desde 1992. Ele permanece onipresente porque todos os navegadores, todos os sistemas operacionais e todos os visualizadores de imagem do planeta o suportam. Esse suporte universal o manteve vivo muito além do ponto em que existem alternativas melhores. Em 2026, o JPEG deve ser seu fallback de último recurso, não seu ponto de partida.

WebP: O Padrão Seguro

O WebP foi desenvolvido pelo Google e lançado em 2010 como um substituto direto tanto para JPEG quanto para PNG. Ele suporta compressão com e sem perdas, suporta transparência (o que o JPEG não faz), e produz arquivos aproximadamente 25 a 30 por cento menores do que o JPEG com qualidade visual equivalente. O suporte dos navegadores tem ficado em aproximadamente 97 por cento por anos e pode ser tratado como universal.

Se você precisa de um único formato que funcione em todos os lugares, não impõe nenhum custo de codificação significativo e é inequivocamente melhor que o JPEG em todas as dimensões, o WebP é esse formato. É o padrão seguro e sensato para a grande maioria das imagens web.

AVIF: O Peso-Pesado

O AVIF é derivado do codec de vídeo AV1 e representa um salto geracional em eficiência de compressão. Com qualidade equivalente, os arquivos AVIF são tipicamente 40 a 50 por cento menores que o JPEG e 20 a 30 por cento menores que o WebP. Para fotografias com gradientes complexos, tons de pele sutis ou superfícies com textura intensa, a relação qualidade-tamanho do AVIF é frequentemente visivelmente melhor porque evita os artefatos de banding de cor que ocasionalmente aparecem no WebP em configurações de qualidade mais baixas.

A contrapartida é a velocidade de codificação. Gerar um arquivo AVIF consome CPU de uma forma que o WebP simplesmente não consome. Codificar um JPEG grande para AVIF pode levar segundos de tempo de CPU. É precisamente por isso que a biblioteca @jsquash (na qual toda esta série é construída) transfere a codificação AVIF para um Web Worker executando WebAssembly em vez de bloquear a thread principal do navegador.

O suporte dos navegadores para AVIF está em aproximadamente 93 por cento no início de 2026 e continua crescendo. A prática padrão é oferecer o AVIF como formato primário com WebP como fallback, usando o elemento HTML <picture> para deixar o navegador selecionar o melhor formato que ele pode processar.

JPEG XL: Acompanhe, Mas Aguarde

O JPEG XL (JXL) merece uma breve menção como um formato emergente com propriedades teóricas impressionantes: compressão quase sem perdas em tamanhos de arquivo minúsculos, suporte para imagens de altíssimo alcance dinâmico e um modelo de decodificação progressiva. Em 2026, ele não tem suporte suficiente nos navegadores para ser implantado em produção sem ressalvas significativas. É um formato para estar ciente e acompanhar, não para publicar.

Formato	Transparência	Animação	vs tamanho JPEG	Velocidade de codificação	Suporte dos navegadores
JPEG	Não	Não	linha de base	Rápida	100%
PNG	Sim	Não	maior	Rápida	100%
WebP	Sim	Sim	~30% menor	Rápida	~97%
AVIF	Sim	Sim	~50% menor	Lenta	~93%
JPEG XL	Sim	Sim	~60% menor	Lenta	Limitado

Fotografia hero? Use AVIF como primário e WebP como fallback e JPEG como última fonte dentro de um elemento <picture>. Gráficos de UI, miniaturas de produtos, imagens de conteúdo geral? Se você quiser oferecer apenas um formato, o WebP deve ser seu padrão. Logos e ícones? SVG, sempre.

Com Perdas vs Sem Perdas: Entendendo a Troca

A árvore de decisão no final desta lição se ramifica em um conceito que as descrições de formato acima mencionaram de passagem, mas não explicaram: compressão com perdas versus sem perdas. Vale a pena dedicar um momento para entender o que essa distinção realmente significa, pois ela molda a decisão de formato para uma categoria significativa de imagens.

Com a compressão com perdas, o codificador descarta permanentemente alguns dados da imagem. Ele faz isso de forma inteligente, visando textura sutil, grão fino e outros detalhes que o olho humano provavelmente não notará em condições normais de visualização, mas o resultado é um arquivo que não pode ser perfeitamente reconstruído no original. O JPEG é um formato exclusivamente com perdas. O WebP e o AVIF podem operar no modo com perdas, que é seu padrão para fotografias.

Com a compressão sem perdas, o codificador reduz o tamanho do arquivo sem descartar nenhum dado. Cada valor de pixel é preservado exatamente, e a imagem original pode ser reconstruída perfeitamente a partir do arquivo comprimido. O PNG é um formato exclusivamente sem perdas. O WebP e o AVIF suportam um modo sem perdas como opção.

Uma analogia útil: pense na compressão com perdas como um resumo de um livro para alguém que quer as ideias principais sem ler cada palavra. O resumo é muito mais curto e captura a maior parte do que importa, mas alguns detalhes se perdem. A compressão sem perdas é mais parecida com um arquivo ZIP — tudo ainda está lá, apenas empacotado de forma mais eficiente. O original sai completo quando você o descompacta.

Quando a distinção importa? Para fotografias e imagens com gradientes de cores suaves, a compressão com perdas funciona extremamente bem. O olho humano é tolerante a pequenas mudanças nos detalhes fotográficos, e um codificador com perdas bem ajustado pode reduzir os tamanhos de arquivo em 60 a 80 por cento sem perda de qualidade perceptível.

Para imagens com texto nítido, linhas finas, elementos de UI ou blocos sólidos de cor plana — como capturas de tela, diagramas, exportações de ícones salvos como imagens raster — a compressão com perdas introduz artefatos visíveis nas bordas e ao redor das letras. Sem perdas é a escolha correta para esses casos.

É por isso que a árvore de decisão separa "fotografia ou gradientes complexos" de "contém texto ou bordas nítidas" em ramos diferentes. O primeiro grupo se beneficia de compressão com perdas. O segundo precisa de compressão sem perdas.

Para formatos com perdas, você controla a troca com uma configuração de qualidade, tipicamente um número de 0 a 100. A relação não é linear: ir da qualidade 60 para 80 produz uma melhoria notável na maioria das imagens. Ir de 80 para 95 é muito mais sutil, enquanto o aumento no tamanho do arquivo é substancial. Uma qualidade de 80 para WebP e em torno de 65 para AVIF são pontos de partida confiáveis que atingem o ponto ideal para a maioria dos conteúdos fotográficos. O resultado serão arquivos pequenos com perda de qualidade mínima, muitas vezes imperceptível.

Um Problema Que Vale Conhecer: Perfis de Cor

Se você já exportou uma fotografia do Lightroom, Capture One ou Photoshop e notou que ela parece vibrante e saturada na sua tela, mas estranhamente sem vida ou opaca depois de colocá-la em uma página web, você encontrou um problema de incompatibilidade de perfil de cor. É uma surpresa comum e a correção é uma única caixa de seleção.

Câmeras e ferramentas de design frequentemente incorporam dados de perfil de cor diretamente no arquivo de imagem. Esses dados dizem ao dispositivo de exibição como interpretar os valores de cor na imagem. A web é construída em um espaço de cores chamado sRGB, mas ferramentas profissionais de fotografia e design frequentemente salvam imagens em espaços de cores mais amplos como Display P3 ou Adobe RGB — e estes representam uma gama mais ampla de cores.

Quando um navegador encontra um desses perfis mais amplos em uma imagem, ele lida com a incompatibilidade de forma inconsistente entre dispositivos e sistemas operacionais. O resultado são cores que parecem erradas, ou metadados desnecessários sendo carregados sem nenhum benefício para o usuário.

A correção é simples: sempre exporte imagens em sRGB e remova o perfil de cor incorporado antes de servir. A maioria dos diálogos de exportação tem uma opção de espaço de cores "web" ou "sRGB". Quando você processar imagens pelo @jsquash mais adiante nesta série, a etapa de codificação remove os perfis incorporados automaticamente.

Se uma imagem parece rica na sua ferramenta de design, mas desbotada na página, abra o Chrome DevTools, vá ao painel Network, clique na requisição da imagem e mude para a aba Preview. Se a prévia parecer bem, mas a imagem renderizada no navegador parecer opaca, o perfil de cor incorporado é provavelmente a causa. A correção é reexportar em sRGB.

A Árvore de Decisão Pré-Voo

Antes que qualquer imagem entre em um pipeline de otimização, uma rápida passagem pelas perguntas a seguir leva menos de dez segundos e elimina as fontes mais comuns de peso desnecessário nos arquivos. Este é o modelo mental que você usará instintivamente quando chegar à Lição 12.

A única exceção notável a esta árvore é a fotografia de alta fidelidade para arquivos digitais com qualidade de impressão, onde a profundidade de cor de 16 bits e a codificação sem perdas importam mais do que o tamanho do arquivo. Para entrega padrão na web, a árvore acima cobre tudo o que você encontrará.

Um caminho que merece destaque específico: nunca use GIF para animação. Um GIF animado é tipicamente 10 a 15 vezes maior do que um WebP animado equivalente com a mesma qualidade visual. Essa não é uma diferença pequena. A animação WebP tem suporte quase universal nos navegadores há anos e não há mais nenhuma razão prática para servir arquivos GIF.

O PNG não apareceu como recomendação principal em nenhum lugar nesta árvore, e isso é intencional. O PNG é um formato sem perdas projetado para imagens com transparência e bordas nítidas — coisas como capturas de tela e gráficos de UI. O WebP sem perdas lida com ambos esses casos de uso enquanto produz arquivos menores. O PNG permanece relevante como fallback universal quando o WebP não é uma opção, mas não deve ser sua primeira escolha.

O que Esta Série Constrói Sobre Essas Decisões

Entender qual formato almejar é o pré-requisito para tudo que se segue. Saber que você quer AVIF com um fallback WebP é uma percepção útil. Saber como produzir esse AVIF dentro do navegador do usuário, sem um servidor, sem ImageMagick e sem que o arquivo bruto jamais cruze a rede — esse é o desafio de engenharia que esta série aborda.

A próxima lição apresenta o @jsquash, a biblioteca WebAssembly que traz a codificação AVIF e WebP de nível Squoosh diretamente para o código da sua aplicação. Ela explica o que é WASM, como o @jsquash envolve bibliotecas de codec profissionais e como é o pipeline de decodificação-codificação antes que qualquer Svelte apareça.

Depois de entender o que a biblioteca é e por que foi projetada da forma como é, construir o otimizador real se torna uma questão de conectar peças que você já entende, em vez de confiar em magia de caixa preta.

Principais Conclusões

SVG é código, não pixels. Use-o para logos, ícones e ilustrações. Sempre execute SVGs exportados pelo SVGO antes de implantar — isso pode reduzir o tamanho do arquivo SVG em até 50%.
AVIF é o melhor formato raster disponível para fotografia em 2026, com WebP como fallback universalmente seguro. O JPEG deve aparecer apenas como fallback de último recurso dentro de um elemento <picture>, nunca como seu formato primário.
Sempre exporte em sRGB e remova perfis de cor incorporados. Perfis de gama ampla como Display P3 e Adobe RGB adicionam peso desnecessário ao arquivo e podem fazer com que as imagens pareçam desbotadas nos navegadores. A correção é uma única caixa de seleção no seu diálogo de exportação.

Leitura Adicional

web.dev: Image Performance - Guia autoritativo do Google sobre tratamento de imagens nos navegadores e impacto nos Core Web Vitals
AVIF Has Landed - Análise detalhada de Jake Archibald sobre as características de codificação do AVIF e o argumento para adotá-lo
Can I Use: AVIF - dados atuais de suporte dos navegadores
Can I Use: WebP - dados atuais de suporte dos navegadores
SVGO no GitHub - a ferramenta padrão de otimização de SVG

Veja Também

Lição 1: Por Que a Otimização de Imagens Importa Mais do Que Você Pensa - o argumento para se preocupar com a escolha de formato em primeiro lugar.
Lição 3: @jsquash e WebAssembly - a próxima lição, cobrindo como os codificadores AVIF e WebP funcionam no navegador via WASM.
Lição 8: Pare de Enviar Imagens de 4000px para um Telefone de 400px - usando a escolha de formato e o elemento picture juntos para a história completa de entrega responsiva.