WebP por padrão em espera para 6.1 após novas objeções dos desenvolvedores líderes do WordPress

Na semana passada, os colaboradores da equipe de desempenho estavam trabalhando para refinar seus patches de acompanhamento para o recurso multi-mime/WebP, depois que o trabalho principal foi mesclado no núcleo para 6.1 no final de julho. Isso inclui itens relacionados menores, como o shim para navegadores não compatíveis e a adição de suporte a PDF, que estão sendo tratados em tickets separados.

A proposta de gerar imagens WebP por padrão para novos uploads de imagens JPEG foi controversa desde o início. Embora os colaboradores patrocinados pelo Google que conduzem o projeto tenham feito algumas revisões após uma rodada inicial de feedback crítico significativo, outros colaboradores continuaram a expressar preocupações que disseram não estar sendo consideradas. Vários colaboradores relataram problemas com o recurso e sugeriram que ele deveria começar por ser opt-in, uma ideia que foi sumariamente descartada antes que o trabalho principal fosse comprometido.

Na semana passada, o desenvolvedor líder do WordPress, Andrew Ozz, avaliou o ticket com novas objeções:

Como @MatthiasReinholz, @eatingrules e outros, acho que essa abordagem talvez esteja faltando. Por que haveria o dobro de arquivos de imagem ocupando muito espaço extra quando metade deles nunca será usado em nenhum lugar?

IMHO uma abordagem melhor seria apenas fazer todos os sub-tamanhos de imagem WEBP. Se os JPEGs forem realmente necessários, eles poderão ser gerados dinamicamente, conforme necessário. Não adianta entupir o armazenamento dos servidores web com todos esses arquivos inúteis.

Por outro lado, se os tamanhos dos arquivos WEBP forem realmente maiores que os JPEGs, isso provavelmente significaria que são necessárias ferramentas melhores, e esse patch é prematuro.

Seis semanas atrás, em resposta a uma reclamação de que os “recursos para conversão seriam enormes”, Adam Silverstein, responsável pelo comprometimento principal do Google, confirmou que os recursos para gerar as imagens no upload “aumentariam dramaticamente”.

“No entanto, os recursos para servir uma imagem serão reduzidos”, disse Silverstein. “Como o upload de imagens é muito raro em comparação com a veiculação de imagens, o esforço extra para compactar e armazenar imagens deve valer a pena.”

Esse é outro problema citado por Ozz em sua objeção a essa abordagem.

“Na verdade, esse aumento dramático do uso de recursos ao carregar uma imagem é um efeito colateral muito ruim aqui”, disse Ozz. “Isso significa que muitos uploads falharão e deixarão os usuários presos. Também aumentará drasticamente as solicitações de suporte para o WordPress e as empresas de hospedagem. Não pense que isso é aceitável. Por causa disso, mesmo que o suporte multi-mime de imagem seja necessário no WordPress, a abordagem atual não parece uma boa solução.”

Aproximadamente 24 horas depois, Felix Arntz, colaborador patrocinado pelo Google, comentou que o mecanismo de fallback WebP para JPEG para navegadores mais antigos estava pronto para confirmação e que ele planejava fazer o commit em alguns dias.

“Por favor, não comite mais nenhum código aqui, a menos que seja para lidar com o aumento dramático de recursos necessários para criar subdimensões de imagem após o upload”, disse Ozz. “Como eu disse acima, esse aumento é inaceitável.

“Existem dados sobre quanto mais recursos (memória, tempo de processamento, etc.) são necessários ao carregar diferentes tamanhos de imagem? Alguma estimativa sobre quantos sites podem ser afetados por isso? Alguma sugestão de como lidar com isso? Você sabe o que acontece quando o pós-processamento de uma imagem enviada falha?

“Francamente, por enquanto, parece que este patch terá que ser revertido e refatorado para resolver isso.”

Adam Silverstein respondeu às suas preocupações com esclarecimentos sobre por que eles escolheram a abordagem atual, antecipando certos casos extremos e, eventualmente, adicionando suporte para formatos como AVIF, uma vez que é mais amplamente suportado:

Eu tendo a concordar com sua avaliação de que todos os sub-tamanhos deveriam ser gerados apenas como WebP, esse era o formato da proposta original. Para a grande maioria dos casos de uso/usuários, isso funcionará melhor. Eu estaria aberto a considerar isso como padrão (com algumas mitigações, veja abaixo).

A razão pela qual decidimos gerar os dois formatos foi por considerações de compatibilidade com versões anteriores para os poucos casos extremos que identificamos em que as imagens WebP podem não funcionar: ou seja, imagens enviadas por e-mail (alguns clientes mais antigos do Outlook/Windows), tags Open Graph (alguns serviços não suportam WebP) e navegadores Safari mais antigos. Uma possibilidade que consideramos seria manter apenas o JPEG em tamanho real para que ele esteja sempre disponível para esses casos extremos.

O suporte “multi-mime” aqui é construído para gerar vários formatos para que seus sites possam fornecer um formato primário e de fallback com algo como o elemento de picture . Isso é menos importante para o WebP, pois é amplamente suportado, mas seria útil para adotar formatos mais recentes, como AVIF por plugins ou núcleo.

Silverstein também disse que a opção de gerar imagens em tempo real é algo que eles precisam descobrir, mas “sentiram-se fora do escopo desse esforço”.

Em resposta à reclamação sobre o aumento dramático nos recursos para upload de imagens, Silverstein disse que está contando com o mecanismo de “repetição” para mitigar esse problema.

“Essa mudança também dobra o número de vezes que o WordPress tentará novamente a regeneração da imagem, portanto, embora o tempo de processamento aumente, não acho que veremos necessariamente um salto nas falhas”, disse ele. “Sei que tivemos problemas para adicionar novos tamanhos no passado, mas isso foi antes de adicionarmos o mecanismo de repetição.”

A equipe por trás do projeto WebP por padrão está mais focada em servir tamanhos de imagem menores no frontend e considera o uso de recursos adicionais no upload um sacrifício necessário para os usuários do WordPress.

“Os recursos adicionais no momento do upload precisam ser ponderados em relação aos recursos reduzidos de servir a imagem WebP menor, especialmente porque o serviço normalmente ocorre várias ordens de magnitude com mais frequência do que o upload”, disse Silverstein.

“Se o upload falhar após todas as tentativas, o usuário terá a mesma experiência atual: ficará com uma imagem quebrada e inutilizável. Isso provavelmente pode ser corrigido, embora eu não ache que essa mudança aumentará as taxas de falha.”

O desenvolvedor líder do WordPress, Dion Hulse, também comentou sobre o ticket para relatar problemas com conversões WebP no diretório de fotos do WordPress:

Apenas observando aqui, que essas conversões adicionais da webp parecem ter sido a principal causa de falhas de upload no diretório de fotos do WordPress nas últimas semanas. Veja #meta6142 e tickets fechados como duplicatas.

Os erros foram geralmente ao longo das linhas de Allowed memory size of 256M bytes exhausted (tried to allocate 90M bytes (obviamente com valores de byte) ao tentar executar a conversão inicial de tamanho original jpeg -> webp.

Não afetou todos os uploads , apenas o de algumas imagens. Potencialmente relacionado ao valor $quality sendo passado para solicitações webp (IIRC o padrão de 82 foi otimizado para jpeg?).

Hulse desativou a conversão de JPEG para WebP como resultado desses erros, pois o diretório de fotos atualmente não usa WebP, mas observou que “pode ser um sinal de que pode valer a pena considerar apenas gerar webps para as imagens redimensionadas, em vez de o arquivo original também.”

Silverstein disse que está investigando os problemas relatados pelo Hulse, pois pode ter exposto um bug.

Ozz circulou de volta para recomendar que fazer sub-tamanhos sob demanda seria uma abordagem melhor que tem processamento mais rápido de imagens carregadas e requisitos de espaço reduzidos, uma vez que as imagens JPEG adicionais não seriam geradas a menos que fossem necessárias. Ele também observou que a “nova tentativa” de pós-processamento de imagem “não funciona tão bem quanto o esperado”.

“A má notícia é que, se o pós-processamento falhar, é provável que o arquivo originalmente carregado permaneça”, disse Ozz. “Então ele será usado em todos os lugares, pois a maior parte do código no WP volta para os tamanhos disponíveis, e o único tamanho será o original. Isso significa que serviremos imagens enormes (média de 4 MB – 8 MB). Uma séria desvantagem.”

Silverstein respondeu às sugestões de Ozz, concordando com muitos, e propôs dois caminhos potenciais para o projeto:

1. Mantenha a infraestrutura multi-mime atual, mas altere os padrões para que apenas arquivos WebP sejam gerados, possivelmente até um tamanho limite além do qual apenas JPEGs seriam gerados. A maioria dos trabalhos existentes continuaria; a filtragem de conteúdo pode ser removida.
2. Reverta a infraestrutura multi-mime e volte para uma abordagem de mímica única, usando WebP para imagens até um tamanho limite e ajustando a camada de compatibilidade para usar os JPEGs que mantemos.

A equipe de desempenho está fazendo mais pesquisas e interrompeu temporariamente o compromisso de qualquer outra coisa até receber feedback sobre a próxima direção do projeto.