Perguntas frequentes

O que é WebP? Por que devo usá-lo?

WebP é um método de compressã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 perda é ajustável para que o usuário possa escolher a equilíbrio entre tamanho do arquivo e qualidade da imagem. O WebP costuma ter uma compressão em média 30% maior que JPEG e JPEG 2000, sem perda de qualidade da imagem (consulte o Estudo comparativo).

O formato WebP visa basicamente criar imagens menores e com melhor aparência para ajudar a tornar a Web mais rápida.

Quais navegadores da Web são compatíveis com o WebP de maneira nativa?

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

  • Compatibilidade com o WebP com perda
    • Google Chrome (computador) 17 ou mais recente
    • Google Chrome para Android versão 25+
    • Microsoft Edge 18+
    • Firefox 65 ou mais recente
    • Opera 11.10 ou mais recente
    • Navegador da Web nativo, Android 4.0+ (ICS)
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • Suporte a WebP com perda, sem perda e Alfa
    • Google Chrome (computador) 23 ou mais recente
    • Google Chrome para Android versão 25+
    • Microsoft Edge 18+
    • Firefox 65 ou mais recente
    • Opera 12.10 ou mais recente
    • Navegador da Web nativo, Android 4.2 ou mais recente (JB-MR1)
    • Lua Pálida 26+
    • Safari 14+ (iOS 14+, macOS Big Sur+)
  • Suporte a animações no formato WebP
    • Google Chrome (computador e Android) 32 ou mais recente
    • Microsoft Edge 18+
    • Firefox 65 ou mais recente
    • Opera 19+
    • Safari 14+ (iOS 14+, macOS Big Sur+)

Consulte também:

Como posso detectar a compatibilidade do WebP com o navegador?

Veicule imagens WebP somente para clientes que possam exibi-las corretamente e, para clientes que não podem, use formatos legados. Felizmente, existem várias técnicas para detectar o suporte a WebP, tanto no lado do cliente quanto no do servidor. Alguns provedores de CDN oferecem detecção de suporte a WebP como parte do serviço.

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

É comum que clientes 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 vai saber que pode enviar imagens WebP com segurança, simplificando bastante a negociação de conteúdo. Consulte os links a seguir para mais informações.

Modernizador

O Modernizr é uma biblioteca JavaScript para detectar convenientemente o 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 oferece suporte a um elemento <picture>, que permite listar vários destinos de imagem alternativos em ordem de prioridade, para que um cliente solicite a primeira imagem candidata a ser exibida corretamente. Veja esta discussão sobre HTML5 Rocks. O elemento <picture> tem suporte a mais navegadores o tempo todo.

No 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. Exemplos

// 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 imagem não gera bloqueios e é assíncrono. Isso significa que qualquer código que dependa do suporte a WebP deve ser colocado preferencialmente na função de callback.

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

Acreditamos profundamente 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 sua entrada e suas sugestões, acreditamos que o WebP se tornará ainda mais útil como um formato gráfico com o tempo.

Como posso converter meus arquivos de imagens pessoais em WebP?

Você pode usar 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 ver 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 de 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 do WebP por mim?

Atualmente, é possível ver arquivos WebP convertendo-os em um formato comum que usa compactação sem perdas, 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 deste site para comparações de fotos lado a lado.

Como consigo 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 do WebP. O código para o 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 com VP8 e usa 14 bits para largura e altura. As dimensões máximas de pixels de uma imagem WebP são 16.383 x 16.383.

Quais espaços de cor são suportados pelo formato WebP?

Consistente com o bitstream VP8, o Web WebP com perda funciona exclusivamente com um formato de imagem Y'CbCr 4:2:0 (muitas vezes chamado de YUV420) de 8 bits. Para mais detalhes, consulte a seção 2, Visão geral do formato do RFC 6386, Guia de decodificação e formato de dados VP8 (links em inglês).

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

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

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

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

  1. Se a imagem de origem estiver no formato ARGB sem perdas, a redução de amostragem 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 fonte está no formato PNG com poucas cores: a conversão para WebP com perda (ou, de modo semelhante a um JPEG com perda) pode resultar em um tamanho de arquivo maior.
  2. Se a origem estiver no formato com perda, o uso da compactação WebP sem perda para capturar a natureza com perda da origem normalmente resultará em um arquivo maior. Isso não é específico do WebP e pode ocorrer ao converter uma origem JPEG em formatos WebP ou PNG sem perda, por exemplo.
  3. Se a origem estiver em um formato com perda e você estiver tentando compactá-la como um WebP com perda com configuração de qualidade mais alta. Por exemplo, a tentativa de converter um arquivo JPEG salvo na qualidade 80 em um arquivo WebP com qualidade 95 normalmente resulta em um arquivo maior, mesmo que os dois formatos tenham perdas. Muitas vezes, avaliar a qualidade da fonte é impossível. Por isso, é aconselhá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 na API equivalente. Por exemplo, segmentar 80% do tamanho do arquivo original pode ser mais robusto.

A conversão de uma fonte JPEG para WebP com perda ou de uma fonte PNG para WebP sem perda não é propensa a surpresas desse 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. É provável que isso sobrecarregue 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 equivale a decodificar o 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 possa ser exibida assim que possível. Isso economiza memória, CPU e esforço de nova pintura 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 faço para usar as vinculações Java libwebp no meu projeto Android?

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

Como criar a biblioteca no Eclipse:

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

    Observação: em geral, a definição de NDK_TOOLCHAIN_VERSION=4.8 melhora o desempenho do build de 32 bits.

  7. Adicione swig/libwebp.jar à pasta libs/ do projeto.

  8. Crie o projeto. Isso vai criar libs/<target-arch>/libwebp.so.

  9. 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. Nesse caso, algumas das etapas descritas acima podem ser reutilizadas.

Como usar libwebp com C#?

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

  1. Crie o libwebp.dll. Isso vai definir WEBP_EXTERN corretamente para exportar as funções da API.

    libwebp> nmake /f Makefile.vc CFG=release-dynamic
    
  2. 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 devo usar WebP animado?

Vantagens do WebP animado em comparação com GIFs animados

  1. O WebP oferece suporte a cores RGB de 24 bits com um canal Alfa de 8 bits, em comparação às cores de 8 bits e Alfa de 1 bits do GIF.

  2. O WebP oferece suporte à compressã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 perdas. As técnicas de compactação com perda do WebP são adequadas para imagens animadas criadas a partir de vídeos do mundo real, uma fonte cada vez mais popular de imagens animadas.

  3. O formato WebP requer menos bytes do que o GIF1. 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.

  4. O WebP leva menos tempo para decodificar na presença de busca. No Blink, rolar ou mudar de guia pode ocultar e mostrar imagens, fazendo com que as animações sejam pausadas e avançadas para um ponto diferente. O uso excessivo da CPU, que resulta na eliminação de frames por animações, também pode exigir que o decodificador avance na animação. Nesses cenários, o WebP animado usa 0,57x mais tempo de decodificação2 total que o GIF, resultando em menos instabilidade durante a rolagem e recuperação mais rápida de picos de uso da CPU. Isso se deve a duas vantagens do WebP sobre o 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 dos frames anteriores de que 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 frames-chave de forma heurística em intervalos regulares, o que a maioria dos codificadores de GIF não faz. Isso melhora drasticamente 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 combinação" (link em inglês) para cada frame, além do método de descarte de frames usado pelo GIF. Isso permite que um frame-chave seja desenhado como se toda a imagem tivesse sido tirada para a cor do plano de fundo, sem forçar o frame anterior a ser do tamanho original.

Desvantagens do WebP animado em comparação com GIFs animados

  1. Na ausência de busca, a decodificação em linha reta do WebP consome mais CPU do que o GIF. O WebP com perda leva 2,2x mais tempo de decodificação que o GIF, enquanto o WebP sem perda leva 1,5x mais.

  2. O suporte a WebP não é tão difundido quanto o suporte a GIFs, que é realmente universal.

  3. Adicionar suporte a WebP a navegadores aumenta o tamanho do código e a superfície de ataque. No Blink, isso representa aproximadamente 1.500 linhas extras de código, incluindo a biblioteca demux do WebP e o decodificador de imagem WebP-side do Blink. Observe que esse problema pode 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 incluídos nos do WebM.

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

Pode fazer sentido a longo prazo oferecer compatibilidade com formatos de vídeo na tag <img>. No entanto, fazer isso agora, com a intenção de que o WebM em <img> possa preencher o papel proposto de WebP animado, é problemático:

  1. Ao decodificar um frame que depende de frames anteriores, o WebM exige 50% mais memória do que o WebP animado para conter o número mínimo de frames anteriores3.

  2. A compatibilidade com o codec de vídeo e o contêiner 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 precisam adicionar cabeçalhos de aceitação indicando quais formatos são compatíveis com as tags de imagem. Até mesmo isso pode ser insuficiente, já que tipos MIME como "video/webm" ou "video/mpeg" ainda não indicam a compatibilidade com codec (por exemplo, VP8 versus VP9). Por outro lado, o formato WebP é efetivamente congelado e, se os fornecedores que o enviam concordarem em enviar o WebP animado, o comportamento do WebP em todos os UAs precisará ser consistente. Além disso, como o cabeçalho "image/webp" já é usado para indicar a compatibilidade com o WebP, não é necessário fazer novas mudanças nos cabeçalhos de aceitação.

  3. A pilha de vídeos do Chromium é otimizada para reprodução suave e presume que há apenas um ou dois vídeos em exibição por vez. Consequentemente, a implementação é agressiva no consumo de recursos do sistema (linhas de execução, memória etc.) para maximizar a qualidade de reprodução. Essa implementação não funciona bem para muitos vídeos simultâneos e precisa ser reformulada para ser adequada para uso com páginas da Web com muitas imagens.

  4. Atualmente, 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:


1 Para todas as comparações entre GIF animado e WebP animado, usamos um corpus de cerca de 7.000 imagens de GIFs animados extraídas aleatoriamente da Web. Essas imagens foram convertidas em WebP animado usando a ferramenta "gif2webp" usando as configurações padrão (criadas a partir da árvore de origem do libwebp mais recente a partir de 08/10/2013). Os números comparativos são a média dos valores das imagens.

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

3 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. O WebP, por outro lado, só precisa que o frame anterior (em RGBA) esteja disponível, que é 4*width*height bytes de memória.

4 A renderização de WebP animado exige a versão 32 ou posterior do Google Chrome