WebP

WebP é um formato de imagem desenvolvido pelo Google em 2010 e padronizado em 2018. Suporta compressão com e sem perdas no mesmo formato, alpha completo (transparência) e animação. Comprime 25-35% menor que JPG com qualidade visual equivalente.

Suporte de navegadores em 2026: ~97% globalmente. O Safari foi o último grande obstáculo, adicionando WebP na versão 14 (setembro de 2020). Os 3% restantes são versões antigas do Android, sobreviventes do IE11 e navegadores embutidos.

O modo com perdas do WebP é baseado em VP8 (codec de vídeo aberto do Google, usado por vídeo WebM). Ele usa previsão de bloco e transformada similar ao H.264, aplicada a um único quadro. O resultado: compressão significativamente melhor do que o DCT da era de 1992 do JPG.

Uso prático:

• Para novo conteúdo web: WebP primeiro, fallback JPG via <picture>.
• Para substituir JPGs existentes: fácil redução de tamanho de 25-35%, sem regressão de qualidade.
• Para substituir PNGs com alpha: WebP sem perdas + alpha é dramaticamente menor que PNG (frequentemente 30-50% do tamanho).
• vs AVIF: AVIF é ainda menor (~20% menor que WebP com qualidade equivalente), mas codifica 10-100× mais devagar e tem suporte de navegadores mais restrito (~93% em 2026). WebP é o padrão mais seguro.

Converta qualquer imagem para WebP em seu navegador via nossos conversores de imagem.

A história da aquisição da On2 — por que o WebP existe: o Google adquiriu a On2 Technologies em fevereiro de 2010 especificamente pelo codec de vídeo VP8, depois lançou o VP8 como código aberto sob uma licença permissiva estilo BSD. O WebP foi anunciado oito meses depois como um formato de imagem estática derivado de um único quadro-chave VP8. O preço de aquisição foi $124,6 milhões — pago em parte para fornecer uma alternativa livre de patentes ao HEIF/HEIC, cujo pool de licenciamento era incompatível com implantação em todos os navegadores. A mesma lógica estratégica produziu VP9, AV1 e eventualmente AVIF.

A assimetria do controle de qualidade: o slider de qualidade com perdas do WebP vai de 0 a 100 como o do JPG, mas as curvas são diferentes — qualidade 80 no WebP é visualmente equivalente a aproximadamente qualidade 90 no JPG com um tamanho de arquivo notavelmente menor. O codificador WebP sem perdas ignora o sinalizador de qualidade completamente; em vez disso, um parâmetro de método -m (0-6) troca tempo de codificação por compressão mais rígida. Ferramentas como cwebp (o codificador de referência), sharp (Node.js) e squoosh (navegador) expõem essas configurações. Para pipelines de build automatizados, qualidade 75-80 com perdas é o ponto ideal típico; para ícones e gráficos onde o alpha importa, sem perdas com método 6 é o ponto ideal. Relacionado: AVIF, sem perdas, com perdas. Referência: Google — WebP, Um novo formato de imagem para a Web.

Exemplo prático

Pegue uma foto hero de 1920×1080, originalmente um JPG de 480 KB com qualidade 85. Converta para WebP com qualidade 80 usando cwebp: cwebp -q 80 hero.jpg -o hero.webp → ~320 KB, uma redução de 33% com qualidade visualmente indistinguível. Converta a mesma fonte para um PNG sem perdas: ~3,2 MB. Agora imagine que a mesma fonte precise de um recorte de canal alpha para uma renderização de produto. Salve como PNG-24 com alpha: ~1,8 MB. Salve como WebP sem perdas: ~650 KB (uma redução de 64%). Em uma página típica de e-commerce com 30 imagens de produtos, trocar fontes JPG/PNG por WebP pode reduzir a carga de imagens de ~6 MB para ~3 MB — melhorando diretamente o LCP (Largest Contentful Paint) em 1-2 segundos em uma conexão 3G, o que alimenta diretamente os Core Web Vitals e a classificação em SEO.

Quando e por que isso importa

O peso das imagens é normalmente o maior contribuinte individual para o peso de páginas móveis, e os Core Web Vitals (especificamente o LCP) são um fator de classificação documentado do Google. A otimização de desempenho mais barata para qualquer site com muitas imagens é adicionar um elemento <picture> com fontes WebP e AVIF ao lado de fallbacks JPG — o Next.js moderno (next/image), Astro, Eleventy e Nuxt fazem isso automaticamente. As poucas situações em que o WebP não é a resposta certa: quando o ativo será editado posteriormente (use um master sem perdas), quando o público-alvo está em navegadores que não o suportam (Android muito antigo, certos webviews embutidos — forneça fallback JPG/PNG) e quando a imagem é uma fotografia para impressão (use TIFF ou o RAW original). Para tudo mais servido a um navegador web moderno em 2026, WebP ou AVIF deve ser o padrão e JPG um fallback legado. Referência: web.dev — Sirva imagens em formatos WebP.