Correndo o risco de soar repetitivo… Uma pagina media tem agora mais de 1300Kb em tamanho e mais de 60% disso estão em imagens. Por isso, se você tiver tempo limitado, então inspecionar e otimizar seus ativos de imagem provavelmente vai render uma maior taxa de retorno.
Por exemplo, o novo proxy de compressão de dados para o Chrome aplica dezenas de diferentes otimizações de conteúdo, mas a otimização de imagens vem quase sempre para o topo. Resultado final? Em média, o uso de dados é reduzida em 50%! A estratégia? Simples, transcodificar todas as imagens para WebP!
Com isso em mente, eu tive a oportunidade de sentar com Stephen Konig (gerente de produto da equipe do WebP), para conversar sobre as notícias mais recentes, o progresso da equipe nos últimos dois anos, onde a WebP está liderando. Você pode ver pelos slides ou assistir ao GDL no YouTube, mas abaixo estão alguns destaques e recursos para ajudar você a começar.
Foco na adoção em 2013
O principal foco e objetivo da equipe do WebP ao longo dos últimos dois anos tem sido o desenvolvimento das características necessárias do formato em si – ou seja, a parte de engenharia. A boa notícia é que o final de 2012 foi um marco importante: suporte para compressão com perda de dados e compressão sem perda de dados, canal alfa, animação, metadados, perfis de cor e muito mais. Com todas essas características em seus devidos lugares, o foco está mudando para tooling e impulsionando a adoção.
Na tradição de ser “beta tester” de seus próprios produtos, já há uma lista grande e crescente de propriedades do Google (Gmail, Drive, Picasa, Instant Previews, Play Magazines, Image Search, YouTube,…), com suporte para WebP. No início do ano, a Chrome Web Store mudou para WebP, vendo 30% de redução de byte, em media, e agora está economizando vários terabytes de banda larga por dia!
Em paralelo, existem hoje mais de 300 mil sites que usam as bibliotecas open sourcePageSpeed, que permitem a transcodificação transparente do WebP no Apache (mod_pagespeed) e no Nginx (ngx_pagespeed), e há uma lista crescente de produtos comerciais (Torbit, EdgeCast), que pode fazer otimizações semelhantes – é difícil argumentar contra a otimização de banda larga!
Largura de banda em tempos de Glass
WebP consegue uma melhor compressão gastando mais ciclos de CPU – que é uma desvantagem inerente de qualquer algoritmo de compressão. Hoje em dia, quando comparada com JPEG, a velocidade de codificação para WebP é 10x mais lenta e a decodificação é 1,4x mais lenta quando feita na CPU. Isso é muita coisa? A resposta depende de sua aplicação: se você estiver gerando imagens únicas e dinâmicas em cada pedido, então a sobrecarga da CPU é algo que você vai notar. Mas se os arquivos são (principalmente) estáticos, então o tempo de codificação não é um problema.
Mais provavelmente, a preocupação não é sobre a codificação, mas sobre velocidade de decodificação. Será que 1.4x vai prejudicar o seu desempenho? Mais uma vez, depende de sua aplicação – como acontece com qualquer métrica de desempenho, meça. A equipe de tecnologia do eBay publicou recentemente uma grande visão geral de varias técnicas de otimização de imagem:
Este teste do webpagetest.org compara o tempo de carregamento da página com WebP vs JPEG. O teste tem uma página com 50 imagens no formato WebP, e outra com as mesmas 50 imagens no formato JPEG. Como a página WebP tinha que baixar menos bytes (47448 vs 757228), ela completava o carregamento bem antes em comparação com a página JPEG… Se você acompanhar as estatísticas de uso do navegador do seu site e descobrir que os usuários do Chrome/Opera são uma fatia considerável, usar imagens WebP vai melhorar o tempo de carregamento da página para esses usuários.
Apesar de o tempo extra de decodificado, o tempo de renderização visual é muito mais rápido devido ao menor número de bytes enviado. Além disso, para um segmento significativo da população, bytes são (literalmente) caros: limites de banda larga são um constrangimento real para muitos usuários, especialmente em dispositivos moveis e no mundo do desenvolvimento.
Implementar WebP em plataformas web e nativas
Implementar WebP em um aplicativo nativo, iOS ou Android, é realmente muito simples: Android 4.x.x e superiores têm suporte nativo para WebP, e há um backport para versões anteriores; no iOS, você pode usar as bibliotecas oficiais fornecidas pela equipe WebP (tutorial, demonstração de app). Desde que você controle a lógica de exibição e a plataforma, você pode converter com segurança todos os bens para WebP e economizar em transferências de dados de e para o dispositivo – WebP também ajuda bastante em uploads!
Na web, as coisas ficam um pouco mais difíceis, mas ainda administráveis. Chrome e Opera têm suporte nativo para WebP, e há um debate aberto com a equipe do Firefox. Existem também os plugins de terceiros para Safari e Chrome Frame que fornecem suporte para IE – no entanto, você não pode confiar que esses plugins estarão presentes. Em vez disso, por enquanto, você tem que passar novamente na detecçãoUser-Agent no servidor, ou usar uma checagem JavaScript – na verdade, existe até umJS polyfill! Finalmente, há um trabalho em andamento para corrigir a negociação Acceptpara tornar todo esse processo muito mais fácil.
A técnica mais popular atualmente, e que é utilizada por PageSpeed e outros produtos de otimização, é contar com a detecção do servidor: executar uma verificação User-Agent, e servir o HTML com links de imagens WebP, ou links não-WebP. Quais são as regras do User-Agent? O PageSpeed é open source, então a resposta está no código. Além disso, para simplificar esse processo, eu traduzi as regras em arquivos de configuração de exemplo para Varnish e Nginx:
Com a detecção acima no devido lugar, Varnish e Nginx irão relatar um cabeçalho extraWebP: lossy, lossless para o servidor de aplicativo, permitindo que seu aplicativo gere HTML personalizado, baseado no suporte para WebP disponível. Por sua vez, os ativos de imagem estática podem ser seguramente armazenados em cache ou no sistema de arquivos local ou em qualquer serviço CDN. A outra única ressalva é que o HTML deve ser marcado com Cache-Control: private para garantir que um cache intermediário não sirva acidentalmente o arquivo errado para o navegador errado.
Para mais detalhes sobre WebP, percorra os slides, e confira o GDL no YouTube para contexto adicional.
Fonte: iMasters
Artigos relacionados:
Como conectar seu headphone bluetooth a mais de um dispositivo
jQuery 3.0 Beta lançado!
Como excluir arquivos mais antigos do que X dias no Linux
[English Required] Palestra super divertida sobre Angular 1.x
Google Chrome não irá mais suportar versões Linux 32 bits
Explicação curta e rápida da função de uma Chave Pública e Privada
Como detectar se o navegador suportar imagens do tipo Webp
Formatação rápida em formato NTFS no Linux
Uma maneira rápida e fácil de obter a foto de um usuário do Facebook