WebP vs AVIF: quando usar cada um (e como sem partir o site)

A pergunta chega de duas direções: ou o PageSpeed Insights sugeriu "serve images in next-gen formats", ou alguém ouviu falar de AVIF e quer perceber se vale a pena. A resposta curta é: WebP em 2026 é o standard razoável, AVIF é o ganho extra quando faz sentido — e fazer mal pode partir o site em navegadores antigos.

Este guia mostra o que escolher para uma PME portuguesa, como implementar com fallback, e quando AVIF compensa o trabalho extra.

Os formatos, em duas frases cada

JPEG. O standard de fotografia há 30 anos. Compressão com perda. Boa para fotos com gradientes. Não suporta transparência. Compatibilidade universal.

PNG. Sem perda. Suporta transparência. Pesado para fotos, ideal para gráficos, logos e screenshots.

WebP. Formato do Google de 2010, mainstream desde 2020. 25-35% mais leve que JPEG na mesma qualidade. Suporta transparência. Hoje funciona em ~97% dos navegadores.

AVIF. Formato AV1 Image, de 2019, mainstream desde 2022. 30-50% mais leve que WebP. Suporta transparência, HDR, animação. Funciona em ~94% dos navegadores (ainda falha em Edge antigo e navegadores de webview de algumas apps).

Comparação de peso real

Para uma foto típica de produto (1600x1200 px, qualidade visual idêntica):

Formato	Peso típico	Reduç. vs JPEG
JPEG q85	280 KB	—
WebP q80	180 KB	-36%
AVIF q60	110 KB	-61%

Para um hero (imagem grande de fundo, 2400x1600):

Formato	Peso	Reduç.
JPEG q80	520 KB	—
WebP q75	320 KB	-38%
AVIF q55	180 KB	-65%

Quanto mais grande e mais fotográfica a imagem, mais AVIF compensa. Para ícones e gráficos pequenos, a diferença esbate-se.

Compatibilidade em 2026

Em caniuse.com (maio 2026):

• WebP: 97.4% de utilizadores globais. Em Portugal, ~98%. Suportado em todos os navegadores modernos. Falha só em IE11 e WebKit antigo (<14).
• AVIF: 94.1% global. Chrome 85+, Firefox 93+, Safari 16.4+, Edge 121+. Falha em iOS <16.4 (~3% dos utilizadores PT em 2026).

Conclusão prática: WebP podes servir sem fallback se aceitas <3% de falhas. AVIF precisa quase sempre de fallback para WebP ou JPEG.

Como implementar com fallback

A tag <picture> resolve isto de forma nativa:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Descrição" width="1600" height="1000">
</picture>

O navegador tenta AVIF primeiro. Se não suporta, passa a WebP. Se nem isso, JPEG. Funciona em 100% dos navegadores — quem suporta o melhor recebe o melhor.

Não esqueças width + height na <img> — evita CLS.

Plugins WordPress que tratam disso

Para uma PME que usa WordPress, fazer <picture> manual em 200 posts não é viável. Os plugins decentes:

• ShortPixel — converte para WebP e AVIF, serve via CDN ou local. Grátis até ~100 imagens/mês, pago 5-30€/mês.
• Smush ou Imagify — alternativas similares, foco em WebP.
• WebP Express — só WebP, grátis, instalação técnica.
• Cloudflare Polish (Pro+) — converte on-the-fly se já tens Cloudflare.

A escolha depende de quantas imagens tens. Para a maioria das PMEs portuguesas com <500 imagens, ShortPixel Free ou Imagify Free chegam.

AVIF: quando vale o esforço (e quando não)

Vale a pena AVIF se:

• Tens muitas fotos grandes (loja com 500+ produtos, portfolio fotográfico, hotel).
• A bandwidth do alojamento ou CDN é fator de custo.
• Trabalhas SEO sério e queres LCP <1.5s mesmo em conexões 4G fracas.
• Já tens um pipeline automático que gera AVIF + WebP + fallback.

Não vale a pena AVIF se:

• O site tem 20 imagens, 100 KB cada. WebP resolve sem dor adicional.
• Não consegues garantir o <picture> com fallback. Servir só AVIF é tirar 3-6% de visitantes.
• A conversão AVIF demora muito no servidor (CPU). Para sites com upload constante de imagens.

A regra: se WebP já te leva ao PageSpeed 90+, não vale a pena complicar com AVIF. Se estás bloqueado a 75 e o LCP é "image", AVIF é a próxima alavanca.

RGPD e imagens — uma nota lateral

Optimização de imagens pode envolver serviços externos (ShortPixel API, Imagify API, Cloudflare). Esses serviços recebem as tuas imagens.

Para imagens públicas do site (produtos, banner), zero problema RGPD.

Para imagens que contenham dados pessoais (fotos de clientes em depoimentos, screenshots de utilizadores), confirma que o serviço de otimização tem cláusulas-tipo da UE ou está em zona UE. Para a maioria, não é preocupação real — mas vale a pena verificar uma vez.

Tamanhos múltiplos: srcset

Independentemente do formato, serve tamanhos diferentes para diferentes dispositivos. Não faz sentido um telemóvel descarregar uma imagem 2400px de largura quando o ecrã tem 400.

<picture>
  <source type="image/avif"
          srcset="hero-480.avif 480w, hero-960.avif 960w, hero-1920.avif 1920w"
          sizes="(max-width: 600px) 480px, (max-width: 1200px) 960px, 1920px">
  <source type="image/webp" srcset="..." sizes="...">
  <img src="hero-960.jpg" alt="...">
</picture>

O WordPress já gera tamanhos automáticos (thumbnail, medium, large) — confirma que estão a ser servidos via srcset. O Next.js faz tudo isto com <Image> da pacote next/image.

O guia completo de otimização de imagens para velocidade cobre estes pontos em detalhe.

Erros frequentes

Vistos em quase todas as auditorias:

1. Converter para WebP e servir mesmo aos navegadores que não suportam. 2-3% de visitantes veem imagem partida.
2. Manter PNG para fotos. PNG de uma foto pesa 5x mais do que JPEG — e 10x mais do que AVIF.
3. Esquecer width/height nas tags <img>. Layout shift garantido.
4. Servir sempre o tamanho máximo. Telemóvel descarrega 1.5 MB para mostrar 400 px.
5. AVIF sem fallback. Resultado: alguns utilizadores recebem imagem vazia.

SEO e formatos modernos

O Google indexa WebP e AVIF sem problemas — confirma na documentação oficial. Não há penalização. Pelo contrário: imagens leves melhoram LCP, que melhora ranking.

O atributo alt continua a ser o que mais conta para SEO de imagem — não o formato. Ver SEO para imagens.

Quando e como JPEG continua a fazer sentido

Em 2026, há cenários onde JPEG ainda é a resposta certa:

• Compatibilidade absoluta — emails, embeds em sites de terceiros, PDFs.
• Editores que não dominam WebP/AVIF — passar um JPEG ao cliente para usar nas redes é mais seguro.
• Pipeline simples — site pequeno sem build automatizado, otimizar 20 JPEGs em mozjpeg é mais rápido que montar conversor.

Para JPEGs que ficam, otimiza com mozjpeg (linha de comando) ou Squoosh.app (browser, grátis). Qualidade 80 + progressive interleave corta mais 20% sem diferença visual.

Animação: GIF, WebM, ou AVIF?

GIFs animados são pesadíssimos — um GIF de 5 segundos pode pesar 4MB. Alternativas:

• WebM (vídeo) com autoplay loop muted — peso ~10x menor, qualidade superior.
• MP4 com mesmas tags — compatibilidade ligeiramente melhor que WebM.
• AVIF animado — peso ainda menor, mas compatibilidade reduzida.

Para "GIF" de produto a rodar ou demo curta, MP4 com <video autoplay muted loop playsinline> é o padrão moderno. Compatibilidade total, peso 90% menor.

Pipeline ideal para projetos novos

Para projetos novos (Next.js, WordPress headless, qualquer site moderno):

1. Originais em PNG ou JPEG alta qualidade no controlo de versão.
2. Build automático gera AVIF + WebP + JPEG fallback em múltiplos tamanhos.
3. <picture> ou componente equivalente serve o melhor formato suportado.
4. CDN à frente caches todas as variantes.

Para Next.js, next/image faz isto out-of-the-box. Para WordPress, plugin de otimização + tema com <picture> resolve.

Lazy loading e prioritização

Independentemente do formato, duas práticas que fazem mais pelo PageSpeed do que mudar de JPEG para AVIF:

• loading="lazy" em imagens abaixo da dobra. Atributo nativo, sem JavaScript. Para a maioria das imagens do site.
• fetchpriority="high" na imagem hero (a do LCP). Diz ao navegador "esta vem primeiro". Reduz LCP em 100-300ms.
• decoding="async" em todas. Permite ao navegador descodificar fora da main thread.

A imagem do hero não deve ter loading="lazy" — pelo contrário, devia ter fetchpriority="high". Erro comum em temas WordPress: lazy load global aplica-se a todas, inclusive a hero. Resultado: LCP atrasa 500ms desnecessariamente.

CDN de imagens dedicados

Para sites com muitas imagens (lojas, portfolios), serviços dedicados de CDN+otimização compensam:

• Cloudinary — manipulação on-the-fly via URL parameters. ~50€/mês para PME.
• Bunny Optimizer — barato, simples. ~10€/mês.
• Cloudflare Images — integrado se já usas Cloudflare. 5€/mês mínimo.

Vantagem: serves a imagem certa no tamanho certo no formato certo automaticamente, sem manter pipelines no teu servidor. Para sites com 1.000+ imagens, esforço poupado paga o serviço.

Em resumo

Para PME portuguesa em 2026: serve WebP por defeito, com fallback para JPEG via <picture>. Considera AVIF se tens muitas imagens grandes (loja, hotel, portfolio) e queres squeeze de PageSpeed extra. WebP corta 30-40% de peso vs JPEG; AVIF corta mais 30-40% vs WebP. Implementação fácil em WordPress com ShortPixel ou Imagify (grátis para a maioria), nativa em Next.js com <Image>. Erros típicos a evitar: servir AVIF sem fallback, esquecer width/height, e manter PNG para fotografia. A escolha do formato é hoje um dos ganhos mais baratos em Core Web Vitals — vale uma tarde de trabalho.

---

No sitesfixe.pt entregamos sites com pipeline de imagens otimizado por defeito — WebP + AVIF com fallback, srcset automático, lazy loading. Se o teu site tem imagens a pesar 1MB+ cada, fala connosco. Sites desde 1.500€.

Lê também:

• Otimizar imagens para velocidade do site
• SEO para imagens: alt text e mais
• Porque é que o teu site é lento

Fontes

• web.dev — Serve images in WebP format
• web.dev — Compress images with AVIF
• Can I use — AVIF support