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.Squoosh CLI, re-ran Lighthouse, and got LCP down to 2.8 seconds in a single afternoon. The client cried. Genuinely.
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.Google's own research, WebP lossless images are 26% smaller than PNGs, and lossy WebP is 25-34% smaller than comparable JPEGs at equivalent quality.
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.ImageMagick side-by-side comparisons plenty of times. On certain highly detailed shots, the size difference drops to under 10%, and sometimes WebP even loses at the same quality setting.
---
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.Can I Use puts global WebP support at over 97% at this point. Safari added full support in version 14 back in 2020. IE is dead and buried. There's no meaningful audience segment that can't receive a WebP image in 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. These are almost always the LCP element. If your hero is a 1.2MB JPEG at 1920px wide, converting to WebP at quality 82 will routinely get you to 380-450KB without visible quality loss.
- 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. Lots of small images loading simultaneously. WebP's consistent 25%+ savings compound here. Faster grid = lower total blocking on 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. Genuinely low impact. A 200KB JPEG versus a 140KB WebP in the middle of a 3,000-word article isn't moving your LCP.
- Ícones e logos: Nenhum. Use SVG. Tenho que dizer isso toda vez. Neither. Use SVG. I have to say this every single time.
- 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. WebP wins here, especially when you're loading 20-30 thumbnails in a grid. That's where byte savings stack up fast.
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.Browser support is now solid for Chrome, Firefox, and Safari. The problem is encoding speed. AVIF is slow to encode, meaningfully slow. Running a batch conversion of 4,000 product images through AVIF on a VPS will take you a long time. WebP is significantly faster to produce.
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.<picture> element with <source type="image/avif"> handles this without any 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. Start with WebP lossy at quality 80-85. Compare against JPEG at quality 75. Take the smaller one that passes the squint test.
- É 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. SVG if possible, PNG if not. WebP lossless is an option but rarely the best one.
- É uma captura de tela com texto? PNG. Sempre PNG. JPEG e WebP introduzem artefatos nas bordas do texto que ficam péssimos. PNG. Always PNG. JPEG and WebP both introduce artefacts around text edges that look terrible.
- É 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. If you're on Cloudflare with Polish enabled, or using Cloudinary, or Imgix, then honestly you don't need to worry much. They'll detect the browser and serve the optimal format. Let the tooling handle it.
- É um site WordPress? Instale ShortPixel ou Imagify e configure para converter no upload. Pronto. Você não precisa gerenciar isso manualmente. Install ShortPixel or Imagify and configure them to convert on upload. Done. You don't need to manually manage this at all.
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. Browser-based, no install, brilliant for one-off comparisons and finding the right quality setting before automating anything.
- Squoosh CLI: Conversão em lote pelo terminal. Uso isso para migrações no nível do projeto. Batch conversion from the terminal. I use this for project-level migrations.
- ShortPixel: Melhor plugin WordPress para conversão automatizada no upload. A configuração com perda é sensata pronta para uso. Best WordPress plugin for automated conversion on upload. The lossy setting is sensible out of the box.
- Cloudflare Polish: Se você já está no Cloudflare Pro, ative isso. Converte e compacta na borda automaticamente. Sem código necessário. If you're already on Cloudflare Pro, turn this on. It converts and compresses at the edge automatically. Zero code required.
- 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. The choice for larger editorial or e-commerce operations where you need format negotiation, responsive sizing, and CDN delivery as a managed service.
- 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. Command-line conversion for server-side workflows. Slower than Squoosh CLI but more flexible for scripted pipelines.
---
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.<img> tag is fine. The <picture> element with source fallbacks made sense when Safari was the holdout. Now it's mainly useful for the AVIF-with-WebP-fallback pattern I mentioned earlier.
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.width and height attributes (or using aspect-ratio in CSS), you'll get layout shift regardless of format. This is one of the most common mistakes I see when people do bulk format migrations. Fix your dimensions.
---
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.