Em 2021 eu tinha um cliente WooCommerce em Birmingham, uma loja de artigos para casa com cerca de 4.000 fotos de produtos, todas JPEGs enormes fotografadas com uma Canon DSLR e enviadas sem nenhum processamento. Seu Largest Contentful Paint estava em 7,2 segundos. Brutal. Converti tudo para WebP usando Squoosh CLI, rodei Lighthouse novamente, e consegui descer o LCP para 2,8 segundos em uma única tarde. O cliente chorou. De verdade.
Mas aqui está a coisa: o mesmo truque teria feito muito pouco para um cliente diferente com quem estava trabalhando no mês seguinte, um site de portfólio de fotojornalismo onde a fidelidade de cor e exportações com qualidade de impressão realmente importavam. WebP foi a escolha errada lá. Usei JPEG com configurações agressivas de exportação do Lightroom em vez disso, e a diferença de desempenho foi negligenciável porque as imagens já estavam dimensionadas corretamente.
Então vamos conversar sobre isso direito. Não é "WebP é sempre melhor" e não é "JPEG é um clássico por uma razão." A resposta real é mais situacional do que qualquer um dos lados admite.
---
O Que Realmente é Diferente por Baixo do Capô
JPEG existe desde 1992. Usa compressão por transformada discreta de cosseno, que é brilhante para fotografias, mas começa a desmoronar em taxas de compressão altas porque introduz aqueles artefatos em blocos que todos conhecem. A maioria dos desenvolvedores web sabe disso.
WebP foi lançado pelo Google em 2010 e usa um modelo de codificação preditiva emprestado do codec de vídeo VP8. Em resumo: ele modela as relações espaciais entre pixels de forma mais inteligente, o que significa que consegue comprimir mais qualidade em menos bytes. De acordo com a própria pesquisa do Google, imagens WebP sem perdas são 26% menores que PNGs, e WebP com perdas é 25-34% menor que JPEGs comparáveis na mesma qualidade.
Esses números se sustentam na prática. Na maioria das vezes.
Onde a diferença realmente aparece
A economia de 25-34% tende a se materializar em fotografias naturais com gradientes suaves, fotos de produtos em fundos brancos e imagens lifestyle. A diferença diminui bastante em detalhes de alta frequência: texturas de tecido apertado, folhagem densa, padrões arquitetônicos com muita repetição. Testei isso com comparações lado a lado do ImageMagick muitas vezes. Em certas fotos altamente detalhadas, a diferença de tamanho cai para menos de 10%, e às vezes WebP até perde na mesma configuração de qualidade.
---
Suporte a navegadores em 2026: Isso ainda é uma conversa?
Honestamente, o suporte a navegadores era o argumento real para ficar com JPEG lá em 2018. Internet Explorer. Safari sendo lento para adotar. Tudo isso.
Acabou. Can I Use coloca o suporte global a WebP em mais de 97% neste ponto. Safari adicionou suporte completo na versão 14 em 2020. IE está morto e enterrado. Não há segmento de público significativo que não possa receber uma imagem WebP em 2026.
O único caso extremo que ainda encontro é: se você está servindo imagens como anexos de email ou as incorporando em exportações de PDF geradas no servidor, alguns pipelines de renderização mais antigos falham com WebP. É só isso. Para tudo entregue pelo navegador, o argumento sobre suporte acabou.
---
Core Web Vitals: Onde a Escolha de Formato Realmente Faz Diferença
LCP (Largest Contentful Paint) é a métrica de Core Web Vitals mais diretamente afetada pelo formato de imagem. Ela mede quanto tempo leva para o maior elemento visível carregar. Se esse elemento é uma imagem (e geralmente é em sites de marketing e e-commerce), então formato, tamanho e método de entrega importam enormemente.
Aqui está um detalhamento prático de onde vi a escolha de formato fazer uma diferença real:
- Imagens hero: Essas são quase sempre o elemento de LCP. Se seu hero é um JPEG de 1.2MB com 1920px de largura, converter para WebP com qualidade 82 vai rotineiramente colocá-lo entre 380-450KB sem perda visível de qualidade.
- Grade de imagens de produto: Muitas imagens pequenas carregando simultaneamente. A economia consistente de 25%+ do WebP se compõe aqui. Grade mais rápida = menor bloqueio total no mobile.
- Imagens inline de post de blog: Impacto genuinamente baixo. Um JPEG de 200KB versus um WebP de 140KB no meio de um artigo de 3.000 palavras não está movimentando seu LCP.
- Ícones e logos: Nenhum. Use SVG. Tenho que dizer isso toda vez.
- Miniaturas em páginas de arquivo: WebP vence aqui, especialmente quando você está carregando 20-30 miniaturas em uma grade. É aí que a economia de bytes se acumula rápido.
Seahawk teve um projeto fintech no ano passado onde o site de marketing tinha 14 imagens acima da dobra rodando em um carrossel hero. Loucura, mas o cliente insistiu. Converter todas as 14 de JPEG para WebP com qualidade 80 e servi-las via CDN Cloudflare reduziu o LCP deles de 4.1 para 2.3 segundos no mobile. O carrossel ainda era uma ideia terrível, mas pelo menos carregava rápido.
---
A Questão do AVIF
Toda vez que escrevo sobre WebP alguém pergunta sobre AVIF. Justo.
AVIF é o próximo passo. É baseado no codec de vídeo AV1, produz arquivos ainda menores que WebP (frequentemente 20-30% menores novamente em fotografias), e lida adequadamente com conteúdo HDR. O suporte dos navegadores agora é sólido para Chrome, Firefox e Safari. O problema é a velocidade de codificação. AVIF é lento para codificar, significativamente lento. Executar uma conversão em lote de 4.000 imagens de produtos através de AVIF em uma VPS vai levar você um tempo considerável. WebP é significativamente mais rápido de produzir.
Meu pensamento atual: use WebP como seu formato de entrega padrão. Se você está construindo um site de alto tráfego onde os ganhos extras de compressão AVIF justificam a sobrecarga de codificação, sirva AVIF para navegadores que o suportam com fallback para WebP. O elemento <picture> com <source type="image/avif"> resolve isso sem nenhum JavaScript.
Não deixe a paralisia do AVIF mantê-lo no JPEG. WebP é o padrão pragmático correto neste momento.
---
Meu Fluxo de Trabalho Real para Escolher um Formato
Depois de 9 anos e mais de 12.000 sites, é mais ou menos assim que penso sobre isso:
- É uma fotografia ou imagem fotorrealista? Comece com WebP com perda em qualidade 80-85. Compare com JPEG em qualidade 75. Pegue o menor que passa no teste do apertar de olhos.
- É um gráfico, logo ou ilustração com cores sólidas? SVG se possível, PNG se não. WebP sem perda é uma opção, mas raramente é a melhor.
- É uma captura de tela com texto? PNG. Sempre PNG. JPEG e WebP introduzem artefatos nas bordas do texto que ficam péssimos.
- É servido por um CDN moderno que faz negociação de formato automaticamente? Se você está no Cloudflare com Polish ativado, ou usando Cloudinary, ou Imgix, honestamente você não precisa se preocupar muito. Eles detectarão o navegador e servirão o formato ideal. Deixe a ferramenta fazer isso.
- É um site WordPress? Instale ShortPixel ou Imagify e configure para converter no upload. Pronto. Você não precisa gerenciar isso manualmente.
Uma nota sobre configurações de qualidade
Qualidade 80 não é qualidade 60. Vejo desenvolvedores configurar qualidade WebP em 60 porque "ainda é melhor que JPEG" e depois se perguntam por que clientes reclamam de fotos de produtos embaçadas. Faça QA visual adequadamente. Eu executo cada decisão de formato através do Squoosh no navegador, alternando entre original e saída com a ferramenta de split-view. Leva 3 minutos por tipo de imagem e economiza discussões com clientes.
---
Quando JPEG Ainda é a Resposta Certa
Vou dizer abertamente porque não vejo muitas pessoas dizendo: JPEG não é obsoleto.
Se você está construindo um site onde imagens serão baixadas e re-editadas (portfólios de fotografia, banco de imagens, bibliotecas de ativos para imprensa), JPEG ainda faz sentido. É universalmente suportado em toda aplicação de edição de imagem na Terra. A qualidade de exportação WebP em ferramentas como Photoshop melhorou dramaticamente, mas o ecossistema ao redor de JPEG para fluxos de trabalho de pós-processamento é simplesmente mais maduro.
Além disso, se suas imagens já estão bem otimizadas como JPEGs (digamos, abaixo de 100KB para uma imagem de 800px de largura), a conversão para WebP economiza talvez 15-20KB. Não é zero, mas não vale o tempo de engenharia se você está fazendo a conversão manualmente. Escolha suas batalhas.
E se você está imprimindo. Óbvio. WebP é um formato web. Não use para nada que acabe em papel.
---
Ferramentas Práticas Vale a Pena Conhecer
Estas são as ferramentas que eu realmente uso, não uma lista inflada:
- [Squoosh](https://squoosh.app/): Baseado em navegador, sem instalação, brilhante para comparações únicas e encontrar a configuração correta de qualidade antes de automatizar qualquer coisa.
- Squoosh CLI: Conversão em lote pelo terminal. Uso isso para migrações no nível do projeto.
- ShortPixel: Melhor plugin WordPress para conversão automatizada no upload. A configuração com perda é sensata pronta para uso.
- Cloudflare Polish: Se você já está no Cloudflare Pro, ative isso. Converte e compacta na borda automaticamente. Sem código necessário.
- Cloudinary: A escolha para operações editoriais ou de e-commerce maiores onde você precisa de negociação de formato, dimensionamento responsivo e entrega por CDN como um serviço gerenciado.
- ImageMagick: Conversão por linha de comando para fluxos de trabalho no servidor. Mais lento que Squoosh CLI, mas mais flexível para pipelines com scripts.
---
FAQ
WebP é sempre menor que JPEG?
Não. Eu gostaria que as pessoas parassem de falar isso. Em imagens altamente detalhadas, com alta frequência (pense em: fotografia macro de texturas ásperas, fotos arquitetônicas densamente detalhadas), a diferença de tamanho pode ser negligenciável ou até invertida dependendo das configurações do codificador. Teste suas imagens específicas em vez de assumir.
Preciso manter o JPEG original se converter para WebP?
Sim. Sempre mantenha seus originais. WebP é um formato de entrega, não um formato de arquivo. Se você está rodando um site WordPress com ShortPixel, o plugin mantém o original por padrão. Não mude essa configuração.
Converter para WebP vai prejudicar meu SEO de imagens?
Não. O Google indexa imagens WebP sem nenhum problema. Certifique-se de que seu texto alternativo é descritivo e seus nomes de arquivo fazem sentido. O formato não tem efeito na classificação de busca de imagens.
E quanto ao elemento `<picture>` versus apenas servir WebP diretamente?
Se 97%+ dos seus usuários suportam WebP, servir WebP diretamente via tag <img> é aceitável. O elemento <picture> com fallbacks de source fazia sentido quando Safari era o único que não suportava. Agora é principalmente útil para o padrão AVIF-com-fallback-WebP que mencionei antes.
O formato de imagem afeta CLS (Cumulative Layout Shift)?
O formato em si não afeta. Mas se você estiver convertendo imagens e não definir atributos explícitos de width e height (ou usar aspect-ratio em CSS), você terá layout shift independentemente do formato. Este é um dos erros mais comuns que vejo quando as pessoas fazem migrações em massa de formatos. Corrija suas dimensões.
---
Decisões de formato parecem pequenas. Não são. Já vi uma única tarde de otimização de imagens tirar um site de "falhando no Core Web Vitals" para "passando" e mover significativamente as taxas de conversão para clientes de e-commerce. WebP é o padrão certo em 2026 para quase toda fotografia entregue por navegador. Mas é um padrão, não uma regra. Saiba por que está tomando a decisão, teste antes de automatizar e mantenha seus originais.
Leitura relacionada: Sites de Joias de Luxo que Carregam em Menos de 1,5 Segundos, velocidade do WordPress e SEO.