Esta página foi traduzida pela API Cloud Translation.

Perguntas frequentes

O que é WebP? Por que usar?

O WebP é um método de compactação com e sem perda que pode ser usado em uma grande variedade de imagens fotográficas, translúcidas e gráficas encontradas na Web. O grau de compactação com perdas é ajustável para que um usuário possa escolher o compromisso entre tamanho do arquivo e qualidade da imagem. Normalmente, o WebP alcança uma média de 30% mais compactação do que JPEG e JPEG 2000, sem perda de qualidade da imagem (consulte Estudo comparativo).

O formato WebP tem como objetivo criar imagens menores e com melhor aparência que podem ajudar a tornar a Web mais rápida.

Quais navegadores da Web oferecem compatibilidade nativa com WebP?

Os webmasters interessados em melhorar a performance do site podem criar facilmente alternativas WebP otimizadas para as imagens atuais e veiculá-las de forma segmentada para navegadores compatíveis com WebP.

Suporte com perdas ao WebP
- Google Chrome (computador) 17 ou mais recente
- Google Chrome para Android versão 25 ou mais recente
- Microsoft Edge 18+
- Firefox 65 ou versões mais recentes
- Opera 11.10 ou mais recente
- Navegador da Web nativo, Android 4.0+ (ICS)
- Safari 14 ou mais recente (iOS 14 ou mais recente, macOS Big Sur ou mais recente)
Suporte a WebP com perdas, sem perdas e alfa
- Google Chrome (computador) 23 ou mais recente
- Google Chrome para Android versão 25 ou mais recente
- Microsoft Edge 18+
- Firefox 65 ou versões mais recentes
- Opera 12.10 ou mais recente
- Navegador da Web nativo, Android 4.2 ou mais recente (JB-MR1)
- Pale Moon 26 ou mais recente
- Safari 14 ou mais recente (iOS 14 ou mais recente, macOS Big Sur ou mais recente)
Suporte a animações WebP
- Google Chrome (computador e Android) 32 ou mais recente
- Microsoft Edge 18+
- Firefox 65 ou versões mais recentes
- Opera 19 ou mais recente
- Safari 14 ou mais recente (iOS 14 ou mais recente, macOS Big Sur ou mais recente)

Consulte também:

Como posso detectar o suporte do navegador para WebP?

É recomendável veicular imagens WebP apenas para clientes que podem mostrá-las corretamente e usar formatos legados para clientes que não podem. Felizmente, há várias técnicas para detectar a compatibilidade com WebP, tanto no lado do cliente quanto no lado do servidor. Alguns provedores de CDN oferecem detecção de suporte ao WebP como parte do serviço.

Negociação de conteúdo do lado do servidor usando cabeçalhos "Accept"

É comum que clientes da Web enviem um cabeçalho de solicitação "Accept", indicando quais formatos de conteúdo eles estão dispostos a aceitar em resposta. Se um navegador indicar com antecedência que vai "aceitar" o formato image/webp, o servidor da Web saberá que pode enviar imagens WebP com segurança, simplificando muito a negociação de conteúdo. Consulte os links a seguir para mais informações.

Modernizr

O Modernizr (link em inglês) é uma biblioteca JavaScript para detectar com facilidade a compatibilidade de recursos HTML5 e CSS3 em navegadores da Web. Procure as propriedades Modernizr.webp, Modernizr.webp.lossless, Modernizr.webp.alpha e Modernizr.webp.animation.

Elemento `<picture>` do HTML5

O HTML5 oferece suporte a um elemento <picture>, que permite listar vários destinos de imagem alternativos em ordem de prioridade. Assim, um cliente solicita a primeira imagem candidata que pode ser exibida corretamente. Consulte esta discussão no HTML5 Rocks. O elemento <picture> é compatível com mais navegadores o tempo todo.

No seu próprio JavaScript

Outro método de detecção é tentar decodificar uma imagem WebP muito pequena que use um recurso específico e verificar se a operação foi bem-sucedida. Exemplo:

// check_webp_feature:
//   'feature' can be one of 'lossy', 'lossless', 'alpha' or 'animation'.
//   'callback(feature, result)' will be passed back the detection result (in an asynchronous way!)
function check_webp_feature(feature, callback) {
    var kTestImages = {
        lossy: "UklGRiIAAABXRUJQVlA4IBYAAAAwAQCdASoBAAEADsD+JaQAA3AAAAAA",
        lossless: "UklGRhoAAABXRUJQVlA4TA0AAAAvAAAAEAcQERGIiP4HAA==",
        alpha: "UklGRkoAAABXRUJQVlA4WAoAAAAQAAAAAAAAAAAAQUxQSAwAAAARBxAR/Q9ERP8DAABWUDggGAAAABQBAJ0BKgEAAQAAAP4AAA3AAP7mtQAAAA==",
        animation: "UklGRlIAAABXRUJQVlA4WAoAAAASAAAAAAAAAAAAQU5JTQYAAAD/////AABBTk1GJgAAAAAAAAAAAAAAAAAAAGQAAABWUDhMDQAAAC8AAAAQBxAREYiI/gcA"
    };
    var img = new Image();
    img.onload = function () {
        var result = (img.width > 0) && (img.height > 0);
        callback(feature, result);
    };
    img.onerror = function () {
        callback(feature, false);
    };
    img.src = "data:image/webp;base64," + kTestImages[feature];
}

O carregamento de imagens não é bloqueador e é assíncrono. Isso significa que qualquer código que dependa da compatibilidade com WebP deve ser colocado de preferência na função de callback.

Por que o Google lançou o WebP como código aberto?

Acreditamos muito na importância do modelo de código aberto. Com o WebP em código aberto, qualquer pessoa pode trabalhar com o formato e sugerir melhorias. Com suas contribuições e sugestões, acreditamos que o WebP se tornará ainda mais útil como formato gráfico com o tempo.

Como posso converter meus arquivos de imagens pessoais para WebP?

Use o utilitário de linha de comando WebP para converter seus arquivos de imagem pessoais para o formato WebP. Consulte Como usar o WebP para mais detalhes.

Se você tiver muitas imagens para converter, use o shell da plataforma para simplificar a operação. Por exemplo, para converter todos os arquivos jpeg em uma pasta, tente o seguinte:

Windows:

> for /R . %I in (*.jpg) do ( cwebp.exe %I -o %~fnI.webp )

Linux / macOS:

$ for F in *.jpg; do cwebp $F -o `basename ${F%.jpg}`.webp; done

Como posso julgar a qualidade da imagem WebP por conta própria?

No momento, é possível visualizar arquivos WebP convertendo-os em um formato comum que usa compactação sem perda, como PNG, e depois visualizar os arquivos PNG em qualquer navegador ou visualizador de imagens. Para ter uma ideia rápida da qualidade do WebP, consulte a galeria neste site para comparações lado a lado de fotos.

Como faço para acessar o código-fonte?

O código do conversor está disponível na seção de downloads da página do projeto de código aberto WebP. O código do decodificador leve e a especificação VP8 estão no site do WebM. Consulte a página Contêiner RIFF para ver a especificação do contêiner.

Qual é o tamanho máximo de uma imagem WebP?

O WebP é compatível com bitstream do VP8 e usa 14 bits para largura e altura. As dimensões máximas de pixels de uma imagem WebP são 16383 x 16383.

Quais espaços de cores o formato WebP aceita?

Consistente com o fluxo de bits VP8, o WebP com perdas funciona exclusivamente com um formato de imagem Y'CbCr 4:2:0 de 8 bits (geralmente chamado de YUV420). Consulte a seção 2, "Visão geral do formato" da RFC 6386, Guia de formato de dados e decodificação VP8 para mais detalhes.

O WebP sem perda funciona exclusivamente com o formato RGBA. Consulte a especificação de fluxo de bits sem perdas do WebP.

Por que meu arquivo WebP sem perda é diferente do original?

As funções da API Simple Encoding (WebPEncodeLosslessRGB(), WebPEncodeLosslessBGR(), WebPEncodeLosslessRGBA(), WebPEncodeLosslessBGRA()) usam as configurações padrão da biblioteca. Para sem perdas, isso significa que "exato" está desativado. Os valores RGB em áreas totalmente transparentes (ou seja, áreas com valores alfa iguais a 0) serão modificados para melhorar a compactação. Para evitar isso, use WebPEncode() e defina WebPConfig::exact como 1. Consulte a documentação da API Advanced Encoding.

Uma imagem WebP pode ficar maior que a imagem de origem?

Sim, geralmente ao converter de um formato com perda para WebP sem perda ou vice-versa. Isso se deve principalmente à diferença de espaço de cores (YUV420 x ARGB) e à conversão entre eles.

Há três situações típicas:

Se a imagem de origem estiver no formato ARGB sem perda, a redução de resolução espacial para YUV420 vai introduzir novas cores mais difíceis de comprimir do que as originais. Isso geralmente acontece quando a origem está no formato PNG com poucas cores: a conversão para WebP com perda (ou, de maneira semelhante, para um JPEG com perda) pode resultar em um tamanho de arquivo maior.
Se a origem estiver em um formato com perda, usar a compactação WebP sem perda para capturar a natureza com perda da origem geralmente vai resultar em um arquivo maior. Isso não é específico do WebP e pode ocorrer ao converter uma fonte JPEG para os formatos WebP ou PNG sem perda, por exemplo.
Se a origem estiver em formato com perdas e você estiver tentando compactá-la como um WebP com perdas e uma configuração de qualidade mais alta. Por exemplo, tentar converter um arquivo JPEG salvo com qualidade 80 para um arquivo WebP com qualidade 95 geralmente resulta em um arquivo maior, mesmo que ambos os formatos sejam com perdas. Avaliar a qualidade da fonte geralmente é impossível. Por isso, é recomendável diminuir a qualidade do WebP de destino se o tamanho do arquivo for consistentemente maior. Outra possibilidade é evitar o uso da configuração de qualidade e, em vez disso, segmentar um determinado tamanho de arquivo usando a opção -size na ferramenta cwebp ou a API equivalente. Por exemplo, segmentar 80% do tamanho do arquivo original pode ser mais robusto.

A conversão de uma origem JPEG para WebP com perda ou de uma origem PNG para WebP sem perda não causa essas surpresas de tamanho de arquivo.

O WebP é compatível com exibição progressiva ou entrelaçada?

O WebP não oferece uma atualização de decodificação progressiva ou entrelaçada no sentido do JPEG ou PNG. Isso provavelmente vai exercer muita pressão sobre a CPU e a memória do cliente de decodificação, já que cada evento de atualização envolve uma passagem completa pelo sistema de descompactação.

Em média, decodificar uma imagem JPEG progressiva é equivalente a decodificar a de referência três vezes.

Como alternativa, o WebP oferece decodificação incremental, em que todos os bytes de entrada disponíveis do fluxo de bits são usados para tentar produzir uma linha de amostra exibível o mais rápido possível. Isso economiza memória, CPU e esforço de repintura no cliente, além de fornecer indicadores visuais sobre o status do download. O recurso de decodificação incremental está disponível na API Advanced Decoding.

Como usar as vinculações Java do libwebp no meu projeto Android?

O WebP inclui suporte para vinculações JNI às interfaces simples de codificador e decodificador no diretório swig/.

Como criar a biblioteca no Eclipse:

Verifique se o plug-in ADT está instalado com as ferramentas do NDK e se o caminho do NDK está definido corretamente (Preferências > Android > NDK).
Crie um novo projeto: File > New > Project > Android Application Project.
Clone ou descompacte libwebp em uma pasta chamada jni no novo projeto.
Adicione swig/libwebp_java_wrap.c à lista LOCAL_SRC_FILES.
Clique com o botão direito do mouse no novo projeto e selecione Android Tools > Add Native Support ... para incluir a biblioteca no build.
Abra as propriedades do projeto e acesse C/C++ Build > Behaviour. Adicione ENABLE_SHARED=1 à seção Build (Incremental build) para criar libwebp como uma biblioteca compartilhada.

Observação: definir NDK_TOOLCHAIN_VERSION=4.8 geralmente melhora o desempenho do build de 32 bits.
Adicione swig/libwebp.jar à pasta do projeto libs/.
Crie o projeto. Isso vai criar libs/<target-arch>/libwebp.so.
Use System.loadLibrary("webp") para carregar a biblioteca durante a execução.

A biblioteca pode ser criada manualmente com ndk-build e o Android.mk incluído. Algumas das etapas descritas acima podem ser reutilizadas nesse caso.

Como usar libwebp com C#?

O WebP pode ser criado como uma DLL que exporta a API libwebp. Essas funções podem ser importadas em C#.

Crie libwebp.dll. Isso vai definir WEBP_EXTERN corretamente para exportar as funções da API.
```
libwebp> nmake /f Makefile.vc CFG=release-dynamic
```

Adicione libwebp.dll ao projeto e importe as funções desejadas. Se você usar a API simples, chame WebPFree() para liberar os buffers retornados.

[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPEncodeBGRA(IntPtr rgba, int width, int height, int stride,
                                 float quality_factor, out IntPtr output);
[DllImport("libwebp.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int WebPFree(IntPtr p);

void Encode() {
  Bitmap source = new Bitmap("input.png");
  BitmapData data = source.LockBits(
      new Rectangle(0, 0, source.Width, source.Height),
      ImageLockMode.ReadOnly,
      PixelFormat.Format32bppArgb);
  IntPtr webp_data;
  const int size = WebPEncodeBGRA(data.Scan0,
                                  source.Width, source.Height, data.Stride,
                                  80, out webp_data);
  // ...
  WebPFree(webp_data);
}

Por que usar WebP animado?

Vantagens do WebP animado em comparação com o GIF animado

O WebP oferece suporte a cores RGB de 24 bits com um canal Alfa de 8 bits, em comparação com a cor de 8 bits e o Alfa de 1 bit do GIF.
O WebP é compatível com compactação com e sem perda. Na verdade, uma única animação pode combinar frames com e sem perda. O GIF só é compatível com compactação sem perda. As técnicas de compactação com perda do WebP são adequadas para imagens animadas criadas com vídeos do mundo real, uma fonte cada vez mais popular de imagens animadas.
O WebP exige menos bytes do que o GIF¹. Os GIFs animados convertidos em WebPs com perda são 64% menores, enquanto os WebPs sem perda são 19% menores. Isso é especialmente importante em redes móveis.
O WebP leva menos tempo para decodificar na presença de busca. No Blink, rolar ou mudar de guia pode ocultar e mostrar imagens, o que faz com que as animações sejam pausadas e depois avançadas para um ponto diferente. O uso excessivo da CPU, que resulta em animações com perda de frames, também pode exigir que o decodificador avance na animação. Nesses cenários, o WebP animado leva 0,57 vez o tempo total de decodificação² do GIF, resultando em menos instabilidade durante a rolagem e recuperação mais rápida de picos de utilização da CPU. Isso acontece devido a duas vantagens do WebP em relação ao GIF:
- As imagens WebP armazenam metadados sobre se cada frame contém alfa, eliminando a necessidade de decodificar o frame para fazer essa determinação. Isso leva a uma inferência mais precisa de quais frames anteriores um determinado frame depende, reduzindo a decodificação desnecessária de frames anteriores.
- Assim como um codificador de vídeo moderno, o codificador WebP adiciona heuristicamente keyframes em intervalos regulares, o que a maioria dos codificadores GIF não faz. Isso melhora muito a busca em animações longas. Para facilitar a inserção desses frames sem aumentar significativamente o tamanho da imagem, o WebP adiciona uma flag de "método de fusão" para cada frame, além do método de descarte de frames usado pelo GIF. Isso permite que um keyframe seja renderizado como se toda a imagem tivesse sido limpa para a cor de fundo sem forçar o frame anterior a ser de tamanho real.

Desvantagens do WebP animado em comparação com o GIF animado

Sem busca, a decodificação em linha reta de WebP exige mais da CPU do que o GIF. O WebP com perda leva 2,2 vezes mais tempo de decodificação do que o GIF, enquanto o WebP sem perda leva 1,5 vezes mais tempo.
O suporte a WebP não é tão difundido quanto o suporte a GIF, que é praticamente universal.
Adicionar suporte a WebP nos navegadores aumenta a pegada de código e a superfície de ataque. No Blink, isso representa aproximadamente 1.500 linhas adicionais de código, incluindo a biblioteca WebP demux e o decodificador de imagem WebP do lado do Blink. Esse problema pode ser reduzido no futuro se o WebP e o WebM compartilharem mais código de decodificação comum ou se os recursos do WebP forem incluídos no WebM.

Por que não oferecer suporte ao WebM no <img>?

A longo prazo, pode ser interessante oferecer suporte a formatos de vídeo na tag <img>. No entanto, fazer isso agora, com a intenção de que o WebM em <img> possa preencher a função proposta do WebP animado, é problemático:

Ao decodificar um frame que depende de frames anteriores, o WebM exige 50% mais memória do que o WebP animado para armazenar o número mínimo de frames anteriores³.
O suporte a codecs e contêineres de vídeo varia muito entre navegadores e dispositivos. Para facilitar a transcodificação automática de conteúdo (por exemplo, para proxies que economizam largura de banda), os navegadores precisariam adicionar cabeçalhos de aceitação indicando quais formatos as tags de imagem são compatíveis. Mesmo assim, isso pode ser insuficiente, já que tipos MIME como "video/webm" ou "video/mpeg" ainda não indicam a compatibilidade com codecs (por exemplo, VP8 x VP9). Por outro lado, o formato WebP está efetivamente congelado. Se os fornecedores que o enviam concordarem em enviar WebP animado, o comportamento do WebP em todos os UAs será consistente. Além disso, como o cabeçalho de aceitação "image/webp" já é usado para indicar suporte a WebP, não são necessárias novas mudanças no cabeçalho de aceitação.
A pilha de vídeo do Chromium é otimizada para reprodução suave e pressupõe que há apenas um ou dois vídeos sendo reproduzidos por vez. Como resultado, a implementação é agressiva no consumo de recursos do sistema (threads, memória etc.) para maximizar a qualidade da reprodução. Essa implementação não é adequada para muitos vídeos simultâneos e precisa ser redesenhada para uso em páginas da Web com muitas imagens.
No momento, o WebM não incorpora todas as técnicas de compactação do WebP. Como resultado, esta imagem é compactada muito melhor com WebP do que com as alternativas:

¹ Para todas as comparações entre GIF animado e WebP animado, usamos um corpus de cerca de 7.000 imagens de GIF animado coletadas aleatoriamente da Web. Essas imagens foram convertidas para WebP animado usando a ferramenta "gif2webp" com configurações padrão (criadas na mais recente árvore de origem libwebp em 08/10/2013). Os números comparativos são os valores médios dessas imagens.

² Os tempos de decodificação foram calculados usando a libwebp mais recente e o ToT Blink em 08/10/2013 com uma ferramenta de comparativo de mercado. "Tempo de decodificação com busca" é calculado como "Decodifique os cinco primeiros frames, limpe o cache do buffer de frames, decodifique os cinco frames seguintes e assim por diante".

³ O WebM mantém quatro frames de referência YUV na memória, e cada frame armazena (largura+96)*(altura+96) pixels. Para YUV 4:2:0, precisamos de 4 bytes por 6 pixels (ou 3/2 bytes por pixel). Portanto, esses frames de referência usam 4*3/2*(width+96)*(height+96) bytes de memória. O WebP, por outro lado, só precisa do frame anterior (em RGBA) para estar disponível, o que equivale a 4*width*height bytes de memória.

⁴ A renderização de WebP animado exige o Google Chrome versão 32 ou mais recente.

Perguntas frequentes Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.