WP-Optimize nie les allégations de triche des outils de performance

Hier, nous avons publié des allégations de Gijo Varghese contre UpdraftPlus, les créateurs de WP-Optimize. Varghese est le fondateur de FlyingProxy, une société concurrente, et s'identifie comme un « passionné de performance ». Il a accusé le plugin de "tromper Pagespeed et d'autres outils" en cachant le chargement des fichiers JavaScript lorsque les utilisateurs testent leurs sites via des outils de test de performance populaires. Le code utilise un ensemble étrange de noms masqués pour les outils de test, ce qui a attiré ses soupçons.

Varghese a omis de mentionner dans son tweet que c'est ce qui se passe lorsque l'un des paramètres du plugin sous Minify > JS est configuré pour différer JavaScript. Il existe deux paramètres de bouton radio, mais ils prêtent à confusion.

Le premier bouton radio permet aux utilisateurs de différer les fichiers JavaScript sélectionnés. Il indique que les fichiers seront chargés de manière asynchrone (pas la même chose que différer), puis il indique également que les utilisateurs doivent sélectionner le premier bouton radio s'ils souhaitent exclure les scripts des tests de vitesse de page. Il n'est pas clair comment les scripts seront chargés pour l'utilisateur ou pour les sites de test. L'exclusion n'est pas la même chose que le report, donc dans ce cas, l'interface utilisateur des paramètres est quelque peu trompeuse et devrait être plus claire.

La deuxième option radio est destinée aux utilisateurs qui cherchent simplement à différer tout JavaScript. Si l'on sélectionne "Différer l'utilisation de JavaScript (utilisez cette méthode si vous avez besoin d'une prise en charge pour les anciens navigateurs)", il devrait faire exactement ce qu'il décrit dans le lien :

Si l'attribut defer est défini, il spécifie que le script est téléchargé parallèlement à l'analyse de la page et exécuté une fois l'analyse de la page terminée.

Même si l'interface utilisateur indique qu'elle diffère tous les fichiers, WP-Optimize ne charge jamais le JavaScript pour les sites de test de performances. Dans cette deuxième option, l'exclusion des sites de test se produit sans l'autorisation des utilisateurs. Si les utilisateurs l'avaient voulu, ils auraient sélectionné le bouton radio précédent et identifié explicitement les scripts à exclure.

Varghese a omis certains détails importants dans son rapport initial, mais il était exact dans la mesure où certains paramètres induisent en erreur sur ce qu'ils font réellement. Il l'a démontré dans une vidéo de suivi où il n'y a pas de saisie manuelle de scripts à exclure et la deuxième option radio est cochée.

"Ils offrent aux utilisateurs la possibilité de tricher avec les outils de test", a déclaré Varghese. « En outre, l'utilisation de noms tels que « ighth » pour Lighthouse et « tmetr » pour GTmetrix montre clairement ce qu'ils essaient de faire.

"La plupart des utilisateurs essaient de désactiver et d'activer différentes fonctionnalités pour voir laquelle augmente la vitesse/les scores dans les outils de test."

Varghese soutient qu'il n'est pas nécessaire de faire les choses différemment pour tester les outils et les humains, car cela peut être déroutant pour les propriétaires de sites. Son allégation a omis des détails importants et laissé entendre que tout cela est caché dans le code. C'est pour l'un des réglages mais pas pour l'autre. L'interface implique que vous devez saisir les scripts manuellement pour les exclure des tests, mais cela est également trompeur.

WP-Optimize a publié aujourd'hui une réponse publique aux allégations, mais n'a révélé aucun des résultats de l'enquête sur le code qu'ils ont menée. Au lieu de cela, la société a cité une vidéo créée par Peter Wilkinson de Divi Engine, qui affirme que les utilisateurs doivent saisir manuellement des scripts pour que les sites de test les excluent.

Wilkinson est cité comme concluant que "Gijo Varghese a utilisé la tromperie pour promouvoir Flying Pages et Flying Press" en portant cette question à l'attention du public sur Twitter.

"En réalité (d'après mes recherches), WP-Optimize ne "triche" pas les outils Pagespeed lorsque vous installez ou réduisez votre JavaScript", a déclaré Wilkinson.

"Pour 'tricher' les outils, vous devez ajouter manuellement les fichiers JS que vous souhaitez charger de manière asynchrone à un paramètre portant clairement l'étiquette 'Utilisez ceci si vous avez un script complètement indépendant ou si vous souhaitez exclure des scripts des tests de vitesse de page ( PageSpeed Insights, GTMetrix...)" "

Ce n'est pas le cas. Le moyen le plus simple de tester est d'installer le plug-in, d'activer "différer tout JavaScript", puis d'afficher la source pour voir que les outils de performance sont exclus.

Étant donné que la réponse publique de WP-Optimize au problème n'incluait rien de leur enquête sur le code, je les ai recontactés. Leur responsable adjoint, Venkat Raj, n'était pas disponible pour expliquer pourquoi d'autres paramètres du plug-in suppriment silencieusement JS pour les outils de test de performance en cliquant sur un bouton radio. Joe Miles, responsable de la stratégie de l'entreprise, a partagé les dernières informations qu'il a reçues sur la question de Venkat Raj :

"Le paramètre avancé utilisé dans l'allégation est en fait utile pour savoir si les fichiers js/css essentiels ralentissent réellement la page Web ou non. Cette fonctionnalité est par défaut, désactivée et activée uniquement par les utilisateurs avancés qui savent ce qu'ils font.

"Vous pouvez utiliser cette fonctionnalité si vous avez un script complètement indépendant ou si vous souhaitez exclure des scripts des tests de vitesse de page (PageSpeed ​​Insights, GTMetrix...)

« Les scripts indépendants sont par exemple des scripts 'analytics' ou 'pixel'. Ils ne sont pas nécessaires au fonctionnement du site Web. ' Utilisez ceci si vous avez une feuille de style complètement indépendante ou si vous souhaitez exclure les feuilles de style des tests de vitesse de page (PageSpeed ​​Insights, GTMetrix…) '

Ceci s'applique au premier bouton radio. Le deuxième bouton n'indique pas qu'il désactivera tous les scripts lors de l'utilisation d'outils de test - et l'équipe de WP-Optimize ne semble pas non plus savoir qu'il est disponible en cliquant sur un bouton radio.

Miles n'a pas pu confirmer si c'est ainsi qu'il est censé fonctionner ou s'il s'agit d'un bogue. Il ne pouvait pas non plus expliquer pourquoi les noms des sites de test populaires étaient obscurcis dans le code, mais a déclaré que le développeur d'origine "ne fonctionne pas pour nous car il s'agit d'un code open source réutilisé d'ailleurs".

"Cependant, nous pensons qu'il s'agit d'une distraction par rapport aux fausses allégations, et ce qui compte, c'est que l'interface utilisateur soit très claire pour les paramètres, afin que les utilisateurs ne soient pas trompés", a déclaré Miles.

Raul Peixoto, auteur de Fast Velocity Minify (FVM), le plugin à partir duquel WP-Optimize a copié le code, a déclaré qu'il peut confirmer que ce code faisait partie de FVM mais a déclaré qu'il n'était pas utilisé de la même manière :

Le but d'un tel code sur FVM était complètement différent de celui sur WP Optimize et en outre, il fallait que les utilisateurs activent manuellement cette option via wp-admin (elle était désactivée par défaut).

Le but de ce code était de tester de manière sélective l'impact des nouveaux scripts ou plugins sur les performances, et d'aider les développeurs à décider s'ils devaient refactoriser, supprimer ou remplacer les plugins ou scripts lourds.

Cela existait sur FVM pour répondre à des questions comme celles-ci :
« J'ai un site de production et mes performances sont faibles. Quelles seraient les performances si ce plugin n'était tout simplement pas là, mais sans encore le supprimer du site pour les utilisateurs réguliers ? »
"Quelles seraient les performances si je pouvais différer tous les scripts, ou des scripts spécifiques qui ne sont actuellement pas compatibles avec le report, avant d'effectuer ce changement pour tout le monde ?"

Une explication officielle concernant son utilisation sur FVM est disponible sur le forum de support du plugin depuis ce matin.

"Je suppose que les développeurs embauchés par WP Optimize n'ont pas compris ce que cela faisait sur FVM ou sous quels paramètres, ou peut-être, ils ont peut-être été tentés de l'utiliser comme un hack", a déclaré Peixoto.

"Nous devons également nous rappeler soigneusement qu'à cette époque, il n'y avait toujours pas de métriques Web Vitals disponibles publiquement, donc utiliser quelque chose comme ça aurait donné de meilleurs résultats" mesurables ", offrant ainsi un avantage produit."

Piexoto a déclaré qu'il "s'était senti obligé" de supprimer ce code il y a deux ans en raison de la fréquence à laquelle il était abusé par les développeurs qui trichaient sur les tests de leurs clients :

Avance rapide un peu de temps, et j'ai réalisé que certains développeurs l'utilisaient en fait pour tricher sur les tests de leurs clients, je me suis donc senti obligé de prendre la décision sur FVM 3 (déjà fin 2020) de supprimer cette fonctionnalité, qui a été satisfaite par un beaucoup de protestations de développeurs en colère lorsque leurs clients ont commencé à se plaindre de la baisse de leurs scores.

J'ai essayé à ce moment-là d'expliquer qu'avoir un bon score n'était pas la même chose qu'avoir de bonnes métriques Web Vitals, mais j'ai finalement abandonné cela, car certaines personnes se souciaient plus des résultats des tests que des performances réelles.

Après la sortie de FVM 3, je ne fais que le maintenir et faire de petites corrections de bogues lorsqu'elles sont signalées, car je dois me concentrer sur d'autres choses. J'ai supprimé cette fonction et corrigé quelques bogues qui étaient en attente sur la version 3.2.9 et poussé une mise à jour, alors merci de m'en avoir parlé.

Pour une raison quelconque, UpdraftPlus a choisi de fusionner ce code dans WP-Optimize en 2020 et, comme indiqué hier, n'a pas touché au code depuis.

Ce qui semblait être un problème noir sur blanc hier est une situation plus nuancée. L'implémentation du code FVM par WP-Optimize est mal documentée dans l'interface utilisateur et trompeuse sur la façon dont les scripts sont chargés. Cela peut amener les propriétaires de sites à l'activer sans être des utilisateurs avancés, et présente historiquement un fort potentiel d'abus. Lorsque Varghese l'a découvert, il l'a exposé de manière incendiaire, se sentant certain d'avoir trouvé un acte répréhensible en raison de l'obscurcissement inexplicable du code. Cela a aggravé le problème, mais a lancé une conversation plus large et importante.

Les utilisateurs devraient-ils avoir ce type d'accès facile (deux clics) pour désactiver les scripts des outils de test de performance ? Comment les développeurs d'un même secteur peuvent-ils mieux communiquer sur les dommages potentiels pour les utilisateurs qu'ils voient dans les produits des autres ? Quel type d'exigences de documentation du code les agences devraient-elles mettre en œuvre pour éviter une situation comme celle-ci où le code doit être étudié sur plusieurs jours afin de découvrir ce qu'il est censé faire ?