Como detectar suporte ao WebP nos navegadores

O que significa detectar suporte ao WebP?

Detectar suporte ao WebP é identificar, antes de entregar a imagem, se o navegador do usuário consegue decodificar o formato e servir WebP quando há suporte ou JPEG/PNG quando não há. Essa negociação acontece em três camadas: header HTTP Accept, tag HTML <picture> ou verificação em JavaScript no runtime.

Se você gerencia um site WordPress corporativo, conhece bem a tensão. O time de marketing quer páginas leves para campanhas. A TI precisa garantir que nada quebre em navegadores legados que ainda rondam o ambiente da empresa. E você fica no meio, decidindo como entregar imagens modernas sem comprometer a experiência de ninguém.

A boa notícia é que o cenário de 2025 mudou muito em relação a alguns anos atrás. Segundo o índice de compatibilidade do WebP no Can I Use, o formato já passa de 96% de suporte global. Ou seja, a pergunta deixou de ser apenas “como detectar” e passou a ser “como entregar WebP com fallback eficiente para os 4% restantes, sem prejudicar a performance”.

Mesmo com essa adoção alta, detectar suporte ao WebP continua relevante. Navegadores corporativos travados em versões antigas, clientes de e-mail e ferramentas de captura automatizada nem sempre acompanham. E o AVIF começa a surgir como próximo passo, exigindo a mesma lógica de negociação. Vale lembrar que as imagens são um dos maiores vilões da performance no WordPress.

Por que o suporte ao WebP impacta os Core Web Vitals?

O WebP impacta diretamente o LCP (Largest Contentful Paint) porque reduz o peso das imagens sem perder qualidade perceptível. Como a imagem costuma ser o maior elemento da página, entregar um arquivo menor acelera o tempo até o conteúdo principal aparecer.

Os números justificam a escolha. Segundo o estudo do Google sobre redução de peso com WebP, o formato gera arquivos 25-34% menores que JPEG equivalentes e cerca de 26% menores que PNG sem perda. Para uma página com várias imagens, isso significa menos banda consumida e carregamento mais rápido, especialmente no mobile.

Há também o ganho na camada de entrega. Imagens menores reduzem o tráfego em CDN, baixam custo de transferência e melhoram a experiência em conexões lentas. É por isso que tratamos o formato de imagem WebP no contexto Mobile First como parte central de qualquer estratégia de performance.

Quais são os métodos para detectar suporte ao WebP?

Existem três abordagens principais para detectar suporte ao WebP, cada uma operando em uma camada diferente da entrega: no servidor (via header HTTP Accept), no front-end com HTML (tag <picture>) e no front-end em runtime (JavaScript). A escolha depende de quanto controle você tem sobre a infraestrutura e de como o site é construído.

A tabela abaixo compara os métodos para ajudar na decisão técnica.

Como detectar WebP no servidor com o header Accept?

A detecção no servidor é a mais elegante e a que menos pesa no navegador. Quando o browser requisita uma página, ele envia no cabeçalho da requisição quais formatos aceita. Se houver suporte ao WebP, o cabeçalho inclui image/webp dentro do header Accept.

Com essa informação, o servidor entrega WebP para quem suporta e JPEG/PNG para quem não suporta, usando a mesma URL. No Nginx, isso costuma ser resolvido com um bloco map que avalia o header e seleciona o arquivo correto.

Um detalhe é obrigatório aqui: o cabeçalho Vary: Accept. Sem ele, a CDN pode cachear a versão WebP e servir esse arquivo também para navegadores que não suportam, quebrando a imagem. O Vary: Accept instrui o cache a guardar versões diferentes conforme o header de cada visitante.

É justamente por causa desse tipo de configuração que a frase mais importante desta seção é: isso não é configuração de site, é configuração de infraestrutura. Quem não tem controle do servidor depende de uma hospedagem que resolva a negociação na camada certa, com a chave de cache correta.

Como usar a tag picture para fallback WebP em HTML?

A tag <picture> permite oferecer múltiplas versões da mesma imagem e deixar o navegador escolher a melhor que ele consegue decodificar. É a forma mais confiável de garantir fallback sem depender de JavaScript.

A ordem dos <source> define a prioridade. Listamos primeiro o AVIF, depois o WebP e, por fim, o <img> com JPEG ou PNG como fallback universal. O navegador lê de cima para baixo e usa o primeiro formato compatível.

<picture>
  <source type="image/avif" srcset="/assets/imgs/apiki.avif">
  <source type="image/webp" srcset="/assets/imgs/apiki.webp">
  <img src="/assets/imgs/apiki.png" alt="Marca da empresa especializada em WordPress" fetchpriority="high">
</picture>

Repare no atributo fetchpriority="high" no <img>. Quando a imagem é o elemento LCP da página, esse atributo sinaliza ao navegador para priorizar o download, ajudando a melhorar a métrica. Para entender os detalhes do elemento, vale consultar a documentação sobre o elemento <picture> na documentação da MDN.

Como detectar WebP via JavaScript em runtime?

A detecção via JavaScript verifica em tempo de execução se o navegador consegue decodificar uma pequena imagem WebP de teste. A abordagem moderna usa createImageBitmap, que tenta criar um bitmap a partir de um blob WebP e resolve a promise com sucesso ou falha.

async function webpIsSupported() {
  if (!self.createImageBitmap) return false;

  const webpData =
    'data:image/webp;base64,UklGRiQAAABXRUJQVlA4IBgAAAAwAQCdASoCAAEAAQAcJaQAA3AA/v3AgAA=';

  const blob = await fetch(webpData).then((r) => r.blob());

  return createImageBitmap(blob).then(
    () => true,
    () => false
  );
}

Esse método faz sentido em cenários específicos: aplicações SPA, geração de imagens em canvas no cliente ou situações em que você precisa decidir o formato dinamicamente. Para HTML estático, ele não compensa, porque atrasa a decisão até o JavaScript executar e pode prejudicar o LCP. Nesse caso, a tag <picture> é sempre superior.

O exemplo com Modernizr, comum em tutoriais antigos, está praticamente abandonado em projetos modernos e adiciona peso desnecessário. Evite em qualquer projeto novo.

O WordPress entrega WebP automaticamente?

O WordPress aceita upload de WebP de forma nativa desde a versão 5.8, lançada em julho de 2021. Isso significa que você pode subir arquivos WebP pela biblioteca de mídia sem plugin. Para conversão automática de JPEG e PNG em WebP, ainda é preciso uma camada extra.

Existem plugins de conversão que geram versões WebP das imagens enviadas e ajustam as marcações para entregá-las. Eles funcionam, mas há um limite importante: o WordPress não negocia formato automaticamente na camada de servidor. Ou seja, a entrega ideal via header Accept com Vary correto depende da hospedagem, não do core.

É aqui que a infraestrutura faz diferença. Na nossa hospedagem WordPress gerenciada, a negociação de WebP e AVIF acontece no servidor, com Vary: Accept e cache de edge configurados corretamente. Você entrega o formato moderno para cada navegador sem depender de plugin frágil e sem o risco de servir o arquivo errado por um cache mal configurado. Para se aprofundar no tema, o guia do web.dev sobre servir imagens WebP traz boas referências práticas.

Perguntas frequentes sobre detectar suporte ao WebP

Quais navegadores não suportam WebP em 2025?

Em 2025, o suporte ao WebP é praticamente universal nos navegadores modernos (Chrome, Firefox, Edge, Safari e Opera). Os casos sem suporte se concentram em versões muito antigas do Internet Explorer e em alguns navegadores corporativos travados em builds desatualizados. Por isso o fallback para JPEG ou PNG continua sendo uma prática de segurança.

O WebP funciona em e-mail marketing?

O suporte ao WebP em clientes de e-mail é inconsistente. Vários clientes populares ainda não decodificam o formato de forma confiável. Para campanhas de e-mail marketing, a recomendação é manter JPEG ou PNG, deixando o WebP para o site, onde a detecção e o fallback funcionam bem.

Vale a pena migrar de WebP para AVIF?

O AVIF oferece compressão ainda melhor que o WebP em muitos casos, mas o suporte nos navegadores é menor. A estratégia mais segura não é migrar, e sim empilhar: oferecer AVIF como primeira opção na tag <picture>, WebP como segunda e JPEG/PNG como fallback. Assim cada navegador recebe o melhor formato que consegue decodificar.

O WordPress converte JPEG para WebP automaticamente?

Não por padrão. O WordPress aceita upload de WebP nativamente desde a versão 5.8, mas não converte automaticamente JPEG e PNG em WebP. Para isso é preciso um plugin de conversão ou uma hospedagem que gere e entregue as versões WebP na camada de servidor.

Como saber se meu site está entregando WebP corretamente?

Abra as ferramentas de desenvolvedor do navegador, vá na aba Network, recarregue a página e inspecione as requisições de imagem. Verifique se o tipo de conteúdo retornado é image/webp nos navegadores compatíveis. Confirme também se o header Vary: Accept está presente na resposta quando a negociação ocorre no servidor.

Detectar WebP no JavaScript afeta a performance?

Sim, pode afetar. A detecção em JavaScript atrasa a decisão sobre qual imagem carregar até o script executar, o que pode prejudicar o LCP em páginas onde a imagem principal é o maior elemento. Para HTML estático, prefira a tag <picture>, que resolve o fallback antes do paint e sem custo de runtime.

O cabeçalho Vary: Accept quebra o cache de CDN?

Não quebra, mas exige atenção. O Vary: Accept instrui a CDN a armazenar versões diferentes do mesmo recurso conforme o header de cada visitante. Sem ele, a CDN pode servir um arquivo WebP para um navegador incompatível. Com ele configurado de forma correta, o cache funciona normalmente e respeita a negociação de formato.

Conclusão

Detectar suporte ao WebP nos navegadores deixou de ser uma curiosidade técnica e virou uma decisão de arquitetura. O caminho é claro: detectar, negociar, entregar e cachear. Você escolhe a camada conforme o controle que tem sobre a infraestrutura.

Para sites estáticos, a tag <picture> com AVIF, WebP e fallback resolve com elegância. Para aplicações dinâmicas, o JavaScript tem seu lugar. E para sites de alto tráfego, a negociação no servidor com Vary: Accept é a opção mais limpa, desde que a hospedagem suporte essa configuração.

Se você quer entregar WebP e AVIF na camada de servidor, com Vary correto e cache de edge, sem depender de plugins frágeis, conheça a nossa hospedagem WordPress gerenciada. Cuidamos da negociação de formato para que suas imagens cheguem rápidas e corretas em qualquer navegador.