WebP e AVIF: a diferença que seu Core Web Vitals nota

Você roda o PageSpeed Insights. Tira 65 no mobile. Desce nas recomendações. A primeira é sempre: “Sirva imagens em formatos de próxima geração”. Mas suas imagens são JPEG e PNG. Funcionam há 30 anos. Por que mudar?

WebP existe desde 2010. AVIF desde 2019. Ambos entregam qualidade visual similar com muito menos peso. E ainda assim, a maioria dos sites WordPress continua servindo JPEG. Porque “funciona”. Porque mudar parece complicado.

O impacto em desempenho não é marginal. É a diferença entre passar ou reprovar nos Core Web Vitals.

O que realmente significam os números de compressão

Os números que você vê por aí:

• WebP: 25-35% menor que JPEG (mesma qualidade)

• AVIF: 50% ou mais menor que JPEG (mesma qualidade)

Parece abstrato. Até você aplicar num site real.

Uma loja WooCommerce típica: 200 produtos, 4 imagens por produto. 800 imagens no total.

Se cada JPEG pesa em média 400KB:

• JPEG: 320 MB

• WebP (30% menos): 224 MB (96 MB a menos)

• AVIF (50% menos): 160 MB (160 MB a menos)

Agora pensa no visitante. Uma página de produto com 4 imagens:

• JPEG: 1,6 MB para baixar

• WebP: 1,1 MB

• AVIF: 0,8 MB

Numa conexão 4G típica (10 Mbps):

• JPEG: 1,3 segundo só para baixar imagens

• AVIF: 0,6 segundo

Mais da metade do tempo de download. E imagens costumam ser 60 a 80% do peso total da página.

Por que LCP é a métrica que importa

Core Web Vitals tem três métricas principais: LCP (Largest Contentful Paint), FID/INP (interatividade) e CLS (estabilidade visual). Das três, LCP é a mais afetada por imagens.

O LCP mede quanto tempo leva para renderizar o maior elemento visível na tela inicial. Na maioria das páginas, esse elemento é uma imagem: a hero da home, a foto principal do produto, a imagem destacada do artigo.

Google considera “bom” UM LCP inferior a 2.5 segundos. Entre 2.5 e 4 segundos é “precisa melhorar”. Acima de 4 segundos é “ruim”.

Se sua imagem hero JPEG pesa 800KB e você converte para WebP de 240KB, o tempo de download dessa imagem cai dois terços. Se o LCP estava em 3,2 segundos e 1,5 segundo era só download da imagem, você pode chegar a 2,2 segundos. Sai de “precisa melhorar” para “bom”.

Isso não é teoria. É matemática básica de banda.

WebP vs AVIF: qual usar e quando

WebP: suporte universal. Todos os navegadores modernos aceitam há anos. Você pode servir WebP para 100% dos visitantes sem fallback.

AVIF: compressão melhor, suporte mais limitado. Chrome e Firefox aceitam bem. Safari aceita desde 2022, mas com algumas limitações. Navegadores antigos não reconhecem.

A estratégia ótima é servir ambos formatos com fallback:

1. Se navegador suporta AVIF, servir AVIF
2. Se não suporta AVIF mas suporta WebP, servir WebP
3. Se não suporta nenhum, servir JPEG/PNG original

Isso é implementado com elemento HTML <picture>:

<picture>
<source srcset=”imagem.avif” type=”image/avif”>
<source srcset=”imagem.webp” type=”image/webp”>
<img src=”imagem.jpg” alt=”…”>
</picture>

O navegador escolhe sozinho. Sem JavaScript. Sem detecção de user agent.

O problema da conversão em WordPress

WordPress gera múltiplos tamanhos para cada upload: thumbnail, medium, large, e tamanhos custom do tema. Uma imagem pode gerar de 6 a 8 arquivos diferentes.

Para servir WebP e AVIF, você precisa converter cada um desses tamanhos. Uma imagem que gerava 8 arquivos passa a gerar 24 (8 JPEG + 8 WebP + 8 AVIF).

As opções para fazer isso são:

Conversão ao fazer upload. Quando usuário faz upload de imagem, servidor converte para WebP e AVIF automaticamente. Vantagem: imagens ficam prontas imediatamente. Desvantagem: processo de upload fica mais lento, especialmente para AVIF que requer mais CPU.

Conversão em background. Imagem é enviada normalmente e conversão é enfileirada para processar depois. Vantagem: upload é rápido. Desvantagem: imagens recém-enviadas não estão otimizadas imediatamente.

Conversão bulk de biblioteca existente. Imagens já na biblioteca são processadas em lote. Necessário para sites existentes com milhares de imagens não convertidas.

Conversão via serviço externo. Imagens são enviadas para serviço como ShortPixel, Imagify ou Cloudinary que retorna versões otimizadas. Vantagem: não consome recursos do servidor. Desvantagem: dependência de terceiros, custo por imagem, latência de rede.

Para sites profissionais, conversão no próprio servidor é preferível. Você não depende de terceiros, não paga por imagem, e tem controle total sobre qualidade.

A importância do processamento por fila

Se você tem 5.000 imagens na biblioteca e quer converter todas para WebP e AVIF, não pode fazer tudo de uma vez. O servidor vai saturar. O processo vai falhar no meio. O WordPress vai dar timeout.

A solução profissional é usar uma fila de processamento. O WordPress tem o Action Scheduler (integrado ao WooCommerce, mas pode ser usado separadamente).

Um sistema bem projetado:

1. Enfileira todas AS imagens pendentes de conversão
2. Processa UM lote pequeno (5-10 imagens) a cada minuto
3. Mostra progresso no admin: “1.247 de 5.000 processadas”
4. Permite pausar e retomar sem perder estado
5. Detecta e reporta erros por imagem individual

5.000 imagens em hosting compartilhado: 8 a 12 horas em background. Em um VPS: 2 a 3 horas.

Responsive images: o complemento necessário

Converter para WebP/AVIF é metade do trabalho. A outra metade é servir o tamanho correto para cada dispositivo. Um celular com tela de 400px não precisa baixar uma imagem de 2000px. Baixar 5x mais pixels que o necessário é desperdício. E conversão para WebP não resolve isso.

WordPress já gera os tamanhos. O que falta é o tema usar corretamente os atributos srcset e sizes. Assim o navegador escolhe o tamanho adequado.

Um sistema completo de otimização de imagens deve:

• Gerar WebP e AVIF de cada tamanho

• Substituir as <img> do conteúdo por <picture> com os formatos disponíveis

• Incluir srcset com todos os tamanhos

• Aplicar sizes conforme o layout do tema

É mais complexo que só converter formatos. Mas o impacto em desempenho é proporcional.

Controle sobre lazy loading e LCP

Lazy loading (loading="lazy") atrasa o carregamento de imagens fora da tela inicial. Isso melhora o carregamento inicial.

Problema: se você aplica lazy loading na imagem LCP (a hero, a imagem principal), você está atrasando exatamente a métrica mais importante.

O correto:

• Imagens above‑the‑fold (visíveis sem rolar a página) → sem lazy loading. Carregam imediatamente.

• Imagens below‑the‑fold (fora da tela inicial) → com lazy loading. Carregam conforme o usuário rola.

Identificar imagens above‑the‑fold automaticamente é difícil, porque depende do design da página. Sistemas profissionais permitem configurar seletor CSS ou padrões de URL para excluir imagens específicas do lazy loading.

Qualidade adaptativa: quando faz sentido

A qualidade de compressão sempre é um trade‑off: mais qualidade → mais peso; menos qualidade → artefatos visíveis.

O padrão é usar qualidade fixa (80-85 para WebP, 70-75 para AVIF). Funciona na maioria dos casos.

Qualidade adaptativa vai além: ajusta a qualidade conforme o contexto.

• Mobile com conexão lenta → qualidade 70 (velocidade importa mais)

• Desktop com fibra → qualidade 90 (qualidade importa mais)

Em telas pequenas ou conexões ruins, os artefatos de compressão são menos visíveis.

Implementar isso exige detectar o tipo de conexão (via Network Information API ou heurísticas) e servir versões diferentes. É mais complexo e tem casos‑limite problemáticos. Mas, para sites de alto tráfego, a economia de banda pode ser significativa.

Diagnóstico e visibilidade operacional

Um sistema de otimização de imagens que roda em background precisa dar visibilidade:

• Quantas imagens já foram convertidas?

• Quantas ainda faltam?

• Quanto peso foi economizado no total?

• Alguma imagem falhou na conversão?

• A fila está funcionando ou travou?

Sem um dashboard que responda essas perguntas, você não sabe se o sistema está funcionando. Você confia que “algo foi instalado”, mas não consegue verificar os resultados.

Plugins profissionais incluem estatísticas de conversão, progresso de campanhas bulk e diagnósticos da fila. Isso não é um “nice‑to‑have”. É essencial para operar o sistema com confiança.

Implementação prática

Você pode implementar conversão para WebP/AVIF com código custom usando bibliotecas PHP como Imagick ou GD. A conversão em si é simples.

O complexo é a infraestrutura ao redor:

• Fila de processamento

• Substituição do HTML com <picture>

• Lógica de srcset / sizes

• Dashboard de estatísticas

Desenvolvemos o B Image Optimizer para resolver o problema completo. Ele faz:

• Conversão para WebP e AVIF

• Fila baseada no Action Scheduler (para bulk)

• Substituição automática de <img> por <picture>, com srcset

• Controle de lazy loading e exclusões específicas (para proteger o LCP)

• Qualidade adaptativa (opcional)

• Dashboard com estatísticas de peso economizado e progresso de conversão

Tudo isso sem serviços externos. Todo processamento ocorre no seu servidor. Você não paga por imagem, não depende de APIs de terceiros e tem controle total sobre os parâmetros de qualidade.

Perguntas frequentes

Meu servidor suporta AVIF?

Depende das bibliotecas instaladas. Imagick precisa da libheif e libaom. GD no PHP 8.1+ tem suporte básico. Muitos hostings compartilhados ainda não oferecem AVIF; VPS e servidores dedicados geralmente sim. Um bom plugin detecta os formatos que seu servidor suporta e age de acordo.

E os navegadores que não suportam WebP?

Com o elemento <picture>, o navegador escolhe automaticamente o primeiro formato que suporta. Navegadores muito antigos ignoram as tags <source> e carregam o JPEG do fallback <img>. Tudo funciona sem JavaScript e sem detecção manual.

Devo excluir JPEGs originais depois de converter?

Não. Os originais servem como fallback e como fonte para regenerar tudo caso você mude os parâmetros de qualidade. O espaço extra que ocupam é mínimo comparado ao risco de perder a fonte.

Quanto tempo demora conversão bulk?

Depende do servidor e do número de imagens. Como referência: 1.000 imagens em hosting compartilhado comum (processando 5 imagens por minuto) levam cerca de 3 horas. Em um VPS com mais CPU, a taxa pode subir para 20-30 imagens por minuto.

Afeta edição de imagens em WordPress?

Não. Os originais permanecem intactos. Se você edita uma imagem (recortar, rotacionar), a versão editada é convertida automaticamente para os novos formatos. É um processo aditivo, não destrutivo.

Conclusão

WebP e AVIF não são tecnologias experimentais. São padrões maduros, com suporte de navegadores amplo e suficiente para uso em produção.

O impacto nos Core Web Vitals — especialmente no LCP — é mensurável e significativo.

Se seu site WordPress ainda serve imagens em JPEG, você está deixando desempenho na mesa. A conversão tem complexidades, mas elas já estão resolvidas nas ferramentas disponíveis hoje.

A diferença entre um site que passa nos Core Web Vitals e um que não passa muitas vezes está nas imagens. Otimize as imagens, e o resto do trabalho de performance fica muito mais fácil.

Na Baqueiro, a gente otimiza imagens de verdade

A Baqueiro Desarrollo Web desenvolveu o B Image Optimizer para resolver o problema completo de imagens no WordPress. Conversão em background, fallback inteligente, proteção do LCP e dashboard claro. Se seu site perde pontos por causa de imagem pesada, a gente pode ajudar.