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 gráficas, translúcidas e gráficas encontradas na Web. O grau de compactação com perdas é ajustável para que o usuário possa escolher o equilíbrio entre o tamanho do arquivo e a qualidade da imagem. O WebP normalmente alcança uma média de 30% mais compactação do que JPEG e JPEG 2000, sem perda de qualidade de imagem. Consulte o estudo comparativo.

O formato WebP visa criar imagens menores e com melhor aparência que podem ajudar a deixar a Web mais rápida.

Quais navegadores da Web são compatíveis nativamente com WebP?

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

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

Consulte também:

Como posso detectar a compatibilidade do navegador com o WebP?

É recomendado exibir imagens WebP somente para clientes que podem exibi-las corretamente e voltar aos formatos legados para clientes que não podem. Felizmente, há várias técnicas para detectar o suporte ao WebP, tanto no cliente quanto no servidor. Alguns provedores de CDN oferecem a detecção de suporte WebP como parte do serviço.

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

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

Modernizador

O Modernizr é uma biblioteca JavaScript para detectar convenientemente suporte a 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>` HTML5

O HTML5 é compatível com um elemento <picture>, que permite listar vários destinos de imagens alternativos em ordem de prioridade. Assim, um cliente vai solicitar a primeira imagem candidata a ser exibida corretamente. Veja esta discussão sobre HTML5 Rocks (em inglês). O elemento <picture> é aceito por mais navegadores o tempo todo.

Em seu próprio JavaScript

Outro método de detecção é tentar decodificar uma imagem WebP muito pequena que usa um recurso específico e verificar o sucesso. 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 do suporte do WebP deve ser colocado 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 sugestões e sugestões, acreditamos que o WebP será ainda mais útil como um formato gráfico com o tempo.

Como posso converter meus arquivos de imagem pessoais para WebP?

Você pode usar o utilitário de linha de comando WebP para converter arquivos de imagem pessoais para o formato WebP. Consulte Como usar o WebP para ver mais detalhes.

Se você tiver muitas imagens para converter, use o shell da sua 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 avaliar a qualidade da imagem WebP para mim?

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

Como faço para receber 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 (link em inglês). O código do decodificador leve e da especificação VP8 estão no site da WebM (em inglês). Consulte a página Contêiner RIFF para ver a especificação do contêiner.

Qual é o tamanho máximo que uma imagem WebP pode ter?

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

Quais espaços de cor são compatíveis com o formato WebP?

De acordo com o bitstream do VP8, o WebP com perda funciona exclusivamente com um formato de imagem Y'CbCr 4:2:0 de 8 bits (geralmente chamado de YUV420). Para mais detalhes, consulte a Seção 2, "Visão geral do formato" da RFC 6386, Guia de formato e decodificação do VP8.

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

Uma imagem WebP pode ser maior do que a imagem de origem?

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

Existem três situações típicas:

Se a imagem de origem estiver no formato ARGB sem perdas, a redução de espaço espacial para YUV420 introduzirá novas cores que são mais difíceis de compactar do que as originais. Essa situação normalmente pode acontecer quando a origem está no formato PNG com poucas cores: a conversão para WebP com perda (ou, de forma semelhante a um JPEG com perdas) pode resultar em um tamanho de arquivo maior.
Se a origem estiver no formato com perda, o uso da compactação WebP sem perda para capturar a natureza com perda da fonte normalmente resultará em um arquivo maior. Isso não é específico ao WebP e pode ocorrer ao converter uma fonte JPEG em formatos WebP ou PNG sem perdas, por exemplo.
Se a origem estiver no formato com perda e você estiver tentando compactá-la como um WebP com perda, usando uma configuração de qualidade superior. Por exemplo, tentar converter um arquivo JPEG salvo com qualidade 80 em um arquivo WebP com qualidade 95 normalmente resulta em um arquivo maior, mesmo que ambos os formatos tenham perdas. Avaliar a qualidade da origem geralmente é impossível. Portanto, recomendamos 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. Em vez disso, segmente 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 fonte JPEG em WebP com perda ou uma fonte PNG para WebP sem perda não é propensa a surpresas com esse 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 JPEG ou PNG. Isso provavelmente sobrecarregará 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, a decodificação de uma imagem JPEG progressiva é equivalente à decodificação do valor de referência três vezes.

Como alternativa, o WebP oferece decodificação incremental, em que todos os bytes de entrada disponíveis do bitstream são usados para tentar produzir uma linha de amostra que pode ser exibida o assim que possível. Isso economiza memória, CPU e trabalhos de rede novamente no cliente, além de fornecer indicações visuais sobre o status do download. O recurso de decodificação incremental está disponível por meio da API de decodificação avançada.

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

O WebP inclui compatibilidade com vinculações JNI para as interfaces de decodificador e decodificador simples no diretório swig/.

Como criar a biblioteca no Eclipse:

Confira se o plug-in ADT está instalado com as ferramentas do NDK e se o caminho dele está definido corretamente (Preferences > 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 seu 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 seu projeto. Isso criará libs/<target-arch>/libwebp.so.
Use System.loadLibrary("webp") para carregar a biblioteca no momento da execução.

A biblioteca pode ser criada manualmente usando ndk-build e o Android.mk incluído. Nesse caso, é possível reutilizar algumas das etapas descritas acima.

Como faço para usar o libwebp com o 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 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ê usa a API simples, chame WebPFree() para liberar todos 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 à cor 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 bits.
O WebP oferece suporte à compactação com e sem perda. Na verdade, uma única animação pode combinar frames com e sem perda. O GIF é compatível apenas com a compactação sem perdas. As técnicas de compactação com perdas do WebP são adequadas para imagens animadas criadas a partir de vídeos reais, uma fonte cada vez mais conhecida 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 é importante principalmente em redes móveis.
O WebP leva menos tempo para decodificar na presença de busca. No Blink, rolar ou alterar guias pode ocultar e mostrar imagens, fazendo com que as animações sejam pausadas e ignoradas para um ponto diferente. O uso excessivo da CPU que resulta em quedas de animações também pode exigir que o decodificador continue a animação. Nesses cenários, o WebP animado leva 0,57x mais tempo de decodificação total² do que o GIF, resultando em menos instabilidade durante a rolagem e recuperação mais rápida após picos de utilização da CPU. Isso se deve a duas vantagens do WebP em relação a 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, o que reduz a decodificação desnecessária de frames anteriores.
- Assim como um codificador de vídeo moderno, o codificador WebP heurística adiciona frames-chave em intervalos regulares, o que a maioria dos codificadores de GIFs 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 sinalização "método de mesclagem" para cada frame, além do método de descarte de frames que o GIF usa. Isso permite que um frame-chave desenhe como se a imagem inteira tivesse sido apagada à cor de fundo sem forçar o frame anterior em tamanho original.

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

Na ausência da busca, a decodificação de linha reta do WebP é mais intensiva da CPU do que o GIF. O WebP com perda ocupa 2,2 vezes mais tempo de decodificação que o GIF, enquanto o WebP sem perda usa 1,5 vez mais.
A compatibilidade com WebP não é tão ampla quanto a compatibilidade com GIF, que é universalmente universal.
Adicionar compatibilidade com WebP a navegadores aumenta a área de ocupação do código e a plataforma de ataque. No Blink, isso é aproximadamente 1.500 linhas de código extras (incluindo a biblioteca de demux WebP e o decodificador de imagem WebP do Blink). Esse problema poderá ser reduzido no futuro se o WebP e o WebM compartilharem códigos de decodificação mais comuns ou se os recursos do WebP forem resumidos nos de WebM.

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

Talvez seja interessante implementar formatos de vídeo na tag <img> a longo prazo. No entanto, fazer isso agora com a intenção de que o WebM em <img> possa preencher o papel proposto 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³.
A compatibilidade com o codec de vídeo e o contêiner varia muito entre os navegadores e dispositivos. Para facilitar a transcodificação automática do conteúdo (por exemplo, para proxies que economizam largura de banda), os navegadores precisariam adicionar cabeçalhos de aceitação, indicando os formatos compatíveis com as tags de imagem. Isso pode ser insuficiente, já que os tipos MIME, como "video/webm" ou "video/mpeg", ainda não indicam a compatibilidade do codec (por exemplo, VP8 x VP9). Por outro lado, o formato WebP é congelado com eficácia e, se os fornecedores que o enviarem concordarem com o envio do WebP animado, o comportamento do WebP em todos os UAs será consistente. Como o cabeçalho de aceitação "image/webp" já é usado para indicar o suporte do WebP, nenhuma nova mudança no cabeçalho de aceitação será necessária.
A pilha de vídeos do Chromium é otimizada para reprodução suave e pressupõe que há apenas um ou dois vídeos por vez. Como resultado, a implementação é agressiva no consumo de recursos do sistema (linhas de execução, memória etc.) para maximizar a qualidade da reprodução. Essa implementação não é bem dimensionada para vários vídeos simultâneos e precisaria ser reformulada para ser usada com 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 significativamente melhor com o WebP do que as alternativas:

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

² Os tempos de decodificação foram calculados usando o libwebp + ToT Blink mais recente em 08/10/2013 usando uma ferramenta de comparativo de mercado. A decodificação de tempo com busca é calculada como "Decodificar os primeiros cinco frames, limpar o cache de buffer do frame, decodificar os próximos cinco frames e assim por diante".

³ O WebM mantém quatro frames de referência YUV na memória, com cada frame armazenando (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. Por outro lado, o WebP precisaria apenas do frame anterior (em RGBA) estar disponível, que é de 4*width*height bytes de memória.

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