WP-Optimize nega alegações de trapaça nas ferramentas de desempenho

Ontem, publicamos alegações de Gijo Varghese contra UpdraftPlus, os criadores do WP-Optimize. Varghese é fundador da FlyingProxy, uma empresa concorrente, e se identifica como um “entusiasta do desempenho”. Ele acusou o plugin de “enganar o Pagespeed e outras ferramentas” ao ocultar o carregamento de arquivos JavaScript quando os usuários testam seus sites por meio de ferramentas populares de teste de desempenho. O código usa um estranho conjunto de nomes ofuscados para as ferramentas de teste, o que atraiu sua suspeita.

Varghese deixou de mencionar em seu tweet que isso é o que acontece quando uma das configurações do plug-in em Minify> JS está definida para adiar o JavaScript. Existem duas configurações de botão de opção, mas elas são confusas.

O primeiro botão de opção permite que os usuários adiem os arquivos JavaScript selecionados. Ele diz que os arquivos serão carregados de forma assíncrona (não o mesmo que adiar) e também diz que os usuários devem selecionar o primeiro botão de opção se quiserem excluir scripts dos testes de velocidade da página. Não está claro como os scripts serão carregados para o usuário ou para sites de teste. Excluir não é o mesmo que adiar, portanto, neste caso, a interface do usuário de configurações é um pouco enganosa e deve ser mais clara.

A segunda opção de rádio é para usuários que desejam simplesmente adiar todo o JavaScript. Se alguém selecionar “Adiar usando JavaScript (Use este método se precisar de suporte para navegadores mais antigos)”, ele deve fazer exatamente o que descreve no link:

Se o atributo defer estiver definido, ele especifica que o script é baixado em paralelo para analisar a página e executado após a conclusão da análise da página.

Mesmo que a interface do usuário diga que está adiando todos os arquivos, o WP-Optimize nunca carrega o JavaScript para sites de teste de desempenho. Nesta segunda opção, a exclusão dos sites de teste acontece sem a permissão dos usuários. Se os usuários quisessem isso, eles teriam selecionado o botão de opção anterior e identificado explicitamente quais scripts excluir.

Varghese deixou de fora alguns detalhes significativos em seu relatório original, mas foi preciso, pois certas configurações são enganosas sobre o que realmente fazem. Ele demonstrou isso em um vídeo de acompanhamento em que não há entrada manual de nenhum script a ser excluído e a segunda opção de rádio está marcada.

“Eles estão oferecendo uma opção para os usuários enganarem as ferramentas de teste”, disse Varghese. “Além disso, usar nomes como 'ighth' para Lighthouse e 'tmetr' para GTmetrix mostra claramente o que eles estão tentando fazer.

“A maioria dos usuários tenta desabilitar e habilitar diferentes recursos para ver qual deles está aumentando a velocidade/pontuação nas ferramentas de teste.”

Varghese afirma que não há necessidade de fazer as coisas de maneira diferente para testar ferramentas e humanos, pois isso pode ser confuso para os proprietários de sites. Sua alegação deixou de fora detalhes significativos e deu a entender que tudo isso está oculto no código. É para uma das configurações, mas não para a outra. A interface implica que você deve inserir scripts manualmente para excluir do teste, mas isso também é enganoso.

O WP-Optimize publicou uma resposta pública às alegações hoje, mas não revelou nenhum dos resultados da investigação do código que eles concluíram. Em vez disso, a empresa citou um vídeo criado por Peter Wilkinson, da Divi Engine, que afirma que os usuários devem inserir scripts manualmente para que os sites de teste os excluam.

Wilkinson é citado como tendo concluído que “Gijo Varghese usou o engano para promover Flying Pages e Flying Press” ao trazer esta questão à atenção do público no Twitter.

“Na realidade (da minha pesquisa) o WP-Optimize não 'engana' as ferramentas do Pagespeed quando você instala ou reduz o seu JavaScript”, disse Wilkinson.

“Para 'enganar' as ferramentas, você precisa adicionar manualmente os arquivos JS que deseja carregar assíncrono a uma configuração que tenha claramente o rótulo 'Use isso se você tiver um script completamente independente ou gostaria de excluir scripts de testes de velocidade de página ( PageSpeed ​​Insights, GTMetrix…)'”

Este não é o caso. A maneira mais fácil de testar é instalar o plug-in, ativar “adiar todo o JavaScript” e visualizar a fonte para ver se as ferramentas de desempenho foram excluídas.

Como a resposta pública do WP-Optimize ao problema não incluiu nada de sua investigação de código, entrei em contato com eles novamente. Seu vice-líder Venkat Raj não estava disponível para responder por que outras configurações no plug-in removem silenciosamente o JS para ferramentas de teste de desempenho com o clique de um botão de opção. Joe Miles, chefe de estratégia da empresa, compartilhou as últimas informações que recebeu sobre o assunto de Venkat Raj:

“A configuração avançada usada na alegação é realmente útil para descobrir se os arquivos js/css essenciais estão realmente deixando a página da web lenta ou não. Esse recurso é, por padrão, desativado e ativado apenas por usuários avançados que sabem o que estão fazendo.

“Você pode usar esse recurso se tiver um script completamente independente ou quiser excluir scripts de testes de velocidade de página (PageSpeed ​​Insights, GTMetrix…)

“Scripts independentes são, por exemplo, scripts 'analíticos' ou 'pixel'. Eles não são necessários para que o site funcione. ' Use isso se você tiver uma folha de estilo completamente independente ou quiser excluir folhas de estilo dos testes de velocidade de página (PageSpeed ​​Insights, GTMetrix…) '

Isso se aplica ao primeiro botão de opção. O segundo botão não tem nenhuma indicação de que desligará todos os scripts ao usar ferramentas de teste – nem a equipe do WP-Optimize parece estar ciente de que está disponível com o clique de um botão de rádio.

Miles não pôde confirmar se é assim que deve funcionar ou se é um bug. Ele também não conseguiu explicar por que os nomes dos sites de teste populares foram ofuscados no código, mas disse que o desenvolvedor original “não funciona para nós, pois é um código-fonte aberto reaproveitado de outro lugar”.

“No entanto, acreditamos que isso seja uma distração das falsas alegações, e o que importa é que a interface do usuário é muito clara para as configurações, para que os usuários não sejam enganados”, disse Miles.

Raul Peixoto, autor do Fast Velocity Minify (FVM), o plugin do qual o WP-Optimize copiou o código, disse que pode confirmar que esse código fazia parte do FVM, mas disse que não era usado da mesma forma:

A finalidade desse código no FVM era completamente diferente do WP Optimize e, além disso, exigia que os usuários habilitassem manualmente essa opção via wp-admin (estava desabilitada por padrão).

O objetivo desse código era testar seletivamente o impacto de novos scripts ou plug-ins no desempenho e ajudar os desenvolvedores a decidir se deveriam refatorar, remover ou substituir plug-ins ou scripts pesados.

Isso existia no FVM para responder a perguntas como estas:
“Tenho um local de produção e meu desempenho é baixo. Qual seria o desempenho se este plugin simplesmente não estivesse aqui, mas sem removê-lo do site para usuários regulares ainda?”
“Qual seria o desempenho se eu pudesse adiar todos os scripts, ou scripts específicos que não são atualmente compatíveis com adiar, antes de realmente fazer essa alteração para todos?”

Uma explicação oficial sobre seu uso no FVM está disponível no fórum de suporte do plugin a partir desta manhã.

“Suponho que os desenvolvedores contratados pelo WP Optimize não entenderam o que isso estava fazendo no FVM ou em quais configurações, ou talvez tenham se sentido tentados a usá-lo como hack”, disse Peixoto.

“Também devemos lembrar cuidadosamente que, naquela época, ainda não havia métricas do web vitals disponíveis publicamente, portanto, usar algo assim teria gerado melhores resultados 'mensuráveis', oferecendo assim uma vantagem do produto.”

Piexoto disse que “se sentiu compelido” a remover este código há dois anos por causa da frequência com que ele era abusado por desenvolvedores que estavam trapaceando em testes para seus clientes:

Avançando algum tempo, percebi que alguns desenvolvedores estavam realmente usando isso para trapacear nos testes para seus clientes, então me senti compelido a tomar a decisão no FVM 3 (já no final de 2020) para remover esse recurso, que foi atendido por um muitos protestos de desenvolvedores irritados quando seus clientes começaram a reclamar que suas pontuações caíram.

Tentei, naquela época, explicar que ter uma boa pontuação não era o mesmo que ter boas métricas de web vitals, mas acabei desistindo disso, pois algumas pessoas se preocupavam mais com os resultados dos testes do que com o desempenho real.

Após o lançamento do FVM 3, basicamente estou apenas mantendo-o e fazendo pequenas correções de bugs quando relatados, pois tenho que me concentrar em outras coisas. Eu removi essa função e consertei alguns bugs que estavam pendentes na versão 3.2.9 e enviei uma atualização, então obrigado por se referir a mim.

Por qualquer motivo, o UpdraftPlus optou por mesclar esse código no WP-Optimize em 2020 e, conforme relatado ontem, não tocou no código desde então.

O que parecia ser uma questão em preto e branco ontem é uma situação mais sutil. A implementação do código do FVM pelo WP-Optimize é mal documentada na interface do usuário e enganosa sobre como os scripts são carregados. Ele pode levar os proprietários de sites a ativá-lo sem serem usuários avançados e, historicamente, tem um alto potencial de abuso. Quando Varghese o descobriu, ele o expôs de maneira inflamatória, sentindo-se certo de que havia encontrado irregularidades por causa de quão inexplicavelmente ofuscado o código é. Isso complicou a questão, mas iniciou uma conversa mais ampla e importante.

Os usuários devem ter esse tipo de acesso fácil (dois cliques) para desativar scripts para ferramentas de teste de desempenho? Como os desenvolvedores do mesmo setor podem se comunicar melhor sobre possíveis danos aos usuários que eles veem nos produtos de outros? Que tipo de requisitos de documentação de código as agências devem implementar para evitar uma situação como essa em que o código precisa ser investigado ao longo de dias para descobrir o que se destina a fazer?