Equipe de desempenho do WordPress revisa proposta para WebP por padrão – WP Tavern

Há um ano, o WordPress 5.8 introduziu suporte para WebP, permitindo que os usuários carreguem e usem imagens WebP em seu conteúdo. Em março de 2022, a equipe de desempenho mudou para expandir o suporte principal para o formato de imagem, propondo que o WordPress habilite o WebP por padrão. Isso inclui a geração de imagens WebP para novos uploads JPEG e o uso de imagens WebP para o conteúdo do site. Em abril, a controversa proposta foi suspensa após um feedback crítico significativo.

Após meses de pesquisa, a equipe reavaliou sua abordagem e resumiu suas descobertas. A preocupação com a compatibilidade do WebP não parece justificada, pois pesquisas mostram que mais de 97% dos navegadores da Web são compatíveis, assim como mais de 97% dos clientes de e-mail.

Os aplicativos móveis têm forte compatibilidade com o iOS 14+ com suporte para WebP (versões mais antigas serão veiculadas em JPEGs) e Android com suporte para WebP nativamente a partir do Android 4.0. A equipe descobriu que todos os principais leitores de RSS suportam WebP. A única exceção na compatibilidade são os consumidores do Open Graph, que têm suporte misto.

Uma das principais preocupações do feedback anterior foi que a proposta tem o potencial de dobrar a quantidade de espaço em disco usado para imagens, pois geraria miniaturas WebP além dos subtamanhos JPEG. O colaborador da equipe de desempenho Adam Silverstein compartilhou as descobertas da equipe após pesquisar as empresas de hospedagem:

Para avaliar o impacto geral da geração de imagens WebP no armazenamento do site, a equipe pesquisou os provedores de hospedagem. Com um total de 17 respostas, os resultados mostram que o número de arquivos armazenados geralmente não é um problema para a maioria dos hosts/sites, embora o espaço de armazenamento possa se tornar um problema para alguns usuários ao longo do tempo. Ainda assim, para grandes hosts (com 1.000 ou mais sites hospedados), a grande maioria dos sites (> 86%) não seria afetada, mesmo que seus requisitos de armazenamento dobrassem. Também aprendemos que alguns planos de hospedagem de baixo custo com armazenamento limitado também não possuem suporte WebP em sua pilha de hospedagem, o que significa que eles não terão geração de imagem extra de qualquer maneira.

Pode haver algumas suposições embutidas na afirmação de que “o número de arquivos armazenados geralmente não é um problema para a maioria dos hosts/sites”. As respostas à pesquisa da equipe indicaram que 58% dos usuários não seriam afetados pela duplicação de seus requisitos de armazenamento. Apenas 17 anfitriões foram pesquisados ​​e os nomes das empresas não foram incluídos nos dados. Mesmo com uma estimativa de 14% dos sites em risco de estar perto da capacidade, isso tem o potencial de impactar milhões de sites WordPress.

A equipe de desempenho está propondo algumas mudanças notáveis ​​para resolver as preocupações, incluindo o fornecimento de um trecho de JavaScript que detecta navegadores que não possuem suporte a WebP e carrega JPEGs. WebP adicionais por revisões padrão incluem o seguinte:

  • Gerando automaticamente versões WebP de tamanhos de imagem principal em 6.1 por padrão. Os tamanhos de imagem personalizados terão inicialmente que optar por receber versões do WebP geradas automaticamente ou optar por não receber se forem usados ​​exclusivamente para casos especiais em que o WebP não é benéfico ou suportado.
  • Mantendo subtamanhos secundários (WebP) se forem menores que o tipo MIME primário.
  • Gerar imagens WebP apenas para tamanhos de imagem destinados ao uso em conteúdo de front-end voltado para o usuário. Isso evita o desperdício de espaço de armazenamento para imagens WebP que nunca serão usadas.
  • Apresentando um filtro para controlar a geração de tipos MIME adicionais com base em subdimensões de imagem. Isso permite que os desenvolvedores excluam determinados tamanhos de imagem, como aqueles que não são usados ​​no conteúdo de front-end.

A proposta de WebP por padrão só afetará novas imagens carregadas após sua inclusão no core. Ele não geraria automaticamente imagens WebP para uploads existentes. Os usuários que desejam converter uploads anteriores precisariam usar o WP-CLI ou um plugin como Regenerate Thumbnails.

Até agora, as revisões da proposta receberam feedback misto. Alguns são fortemente a favor da nova abordagem e outros encorajaram a equipe a considerar algumas das implicações práticas para os usuários que podem ser impactados.

“Não se pode simplesmente dizer que está tudo bem porque ‘a grande maioria dos sites (> 86%) não seria afetada’”, disse o desenvolvedor do WordPress Jon Brown. “Primeiro, 14% dos termos do WordPress é muito. De alguma forma, precisamos continuar suportando os 2,8% dos sites que ainda executam o PHP 5.6, mas 14% não é significativo?

“É preciso considerar aqui não apenas SE, mas COMO esses 14% dos sites serão afetados, e não apenas hoje, mas também no futuro. Os sites terão que atualizar o armazenamento sem problemas ou ficarão sem espaço em disco e travarão? Ou os backups começam a falhar de repente?”

Vários participantes nos comentários sugeriram que o WordPress adotasse o formato AVIF mais moderno, que tem melhor qualidade e compactação quando comparado ao WebP.

“Como essa iniciativa é essencialmente um aprimoramento progressivo, não faria mais sentido oferecer suporte a formatos de última geração como AVIF, enquanto recua graciosamente?” O desenvolvedor de JavaScript Kevin Batdorf disse. “Então os navegadores vão se encaixar à medida que adicionam suporte ao longo do tempo.

“A mudança para o suporte WebP parece quando o WordPress adicionou a API REST enquanto todos estavam começando a mudar para o GraphQL. O REST é ótimo, assim como o WebP, mas é uma tecnologia de geração atual e ficará obsoleto rapidamente.”

A colaboradora da equipe de desempenho, Bethany Chobanian Lang, disse que o AVIF está no radar deles, mas seu suporte ao navegador ainda está faltando em menos de 70% da web.

A conversa continua nos comentários da atualização e Silverstein também incentivou a participação no ticket do Trac para a abordagem revisada. Os colaboradores da equipe de desempenho pretendem mesclar essa alteração no início do ciclo de lançamento do 6.1 para obter mais testes.

[ad_2]

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *