WP-Optimize respinge acuzațiile de instrumente de performanță înșelate

Ieri, am publicat acuzațiile lui Gijo Varghese împotriva UpdraftPlus, realizatorii WP-Optimize. Varghese este fondatorul FlyingProxy, o companie concurentă, și se identifică ca un „entuziast de performanță”. El a acuzat pluginul că „înșeală Pagespeed și alte instrumente” prin ascunderea fișierelor JavaScript de la încărcare atunci când utilizatorii își testează site-urile prin instrumente populare de testare a performanței. Codul folosește un set ciudat de nume ofuscate pentru instrumentele de testare, ceea ce i-a atras suspiciunea.

Varghese a neglijat să menționeze în tweetul său că acest lucru se întâmplă atunci când una dintre setările pluginului din Minify > JS este setată să amâne JavaScript. Există două setări pentru butoanele radio, dar sunt confuze.

Primul buton radio permite utilizatorilor să amâne fișierele JavaScript selectate. Se spune că fișierele vor fi încărcate asincron (nu la fel cu defer), apoi mai spune că utilizatorii ar trebui să selecteze primul buton radio dacă doresc să excludă scripturile din testele de viteză a paginii. Nu este clar cum vor fi încărcate scripturile pentru utilizator sau pentru site-urile de testare. Excluderea nu este același lucru cu amânarea, așa că, în acest caz, interfața de utilizare a setărilor este oarecum înșelătoare și ar trebui să fie mai clară.

A doua opțiune radio este pentru utilizatorii care doresc pur și simplu să amâne tot JavaScript. Dacă se selectează „Amânați utilizarea JavaScript (Folosiți această metodă dacă aveți nevoie de suport pentru browsere mai vechi),” ar trebui să facă exact ceea ce descrie în link:

Dacă este setat atributul defer , acesta specifică faptul că scriptul este descărcat în paralel cu analizarea paginii și executat după ce pagina a terminat parsarea.

Chiar dacă interfața de utilizare spune că amână toate fișierele, WP-Optimize nu încarcă niciodată JavaScript pentru site-urile de testare a performanței. În această a doua opțiune, excluderea site-urilor de testare are loc fără permisiunea utilizatorilor. Dacă utilizatorii ar fi dorit asta, ar fi selectat butonul radio anterior și ar fi identificat în mod explicit ce scripturi să excludă.

Varghese a omis câteva detalii semnificative în raportul său inițial, dar a fost corect prin faptul că anumite setări induc în eroare cu privire la ceea ce fac de fapt. El a demonstrat acest lucru într-un videoclip ulterior în care nu există nicio introducere manuală a niciunui script de exclus și a doua opțiune radio este bifată.

„Oferă utilizatorilor o opțiune de a înșela instrumentele de testare”, a spus Varghese. „De asemenea, folosirea numelor precum „ighth” pentru Lighthouse și „tmetr” pentru GTmetrix arată clar ce încearcă să facă.

„Majoritatea utilizatorilor încearcă să dezactiveze și să activeze diferite funcții pentru a vedea care dintre ele crește viteza/scorurile în instrumentele de testare.”

Varghese susține că nu este nevoie să faceți lucrurile diferit pentru instrumentele de testare și oamenii, deoarece acest lucru poate fi confuz pentru proprietarii de site-uri. Afirmația sa a omis detalii semnificative și a sugerat că toate acestea sunt ascunse în cod. Este pentru una dintre setări, dar nu pentru cealaltă. Interfața implică faptul că trebuie să introduceți scripturi manual pentru a le exclude de la testare, dar acest lucru este și înșelător.

WP-Optimize a publicat astăzi un răspuns public la acuzații, dar nu a dezvăluit niciunul dintre rezultatele investigației de cod pe care au finalizat-o. În schimb, compania a citat un videoclip creat de Peter Wilkinson de la Divi Engine, care susține că utilizatorii trebuie să introducă manual scripturi pentru ca site-urile de testare să le excludă.

Wilkinson a ajuns la concluzia că „Gijo Varghese a folosit înșelăciunea pentru a promova Flying Pages și Flying Press” pentru a aduce această problemă în atenția publicului pe Twitter.

„În realitate (din cercetările mele) WP-Optimize nu „înșeală” instrumentele Pagespeed atunci când instalați sau reduceți JavaScript”, a spus Wilkinson.

„Pentru a „înșela” instrumentele, trebuie să adăugați manual fișierele JS pe care doriți să le încărcați asincron la o setare care are în mod clar eticheta „Folosiți acest lucru dacă aveți un script complet independent sau doriți să excludeți scripturile din testele de viteză a paginii ( PageSpeed ​​Insights, GTMetrix...)'”

Nu este cazul. Cel mai simplu mod de a testa este să instalați pluginul, să activați „amâna tot JavaScript” și apoi să vizualizați sursa pentru a vedea că instrumentele de performanță sunt excluse.

Deoarece răspunsul public al WP-Optimize la problemă nu includea nimic din investigația lor de cod, i-am contactat din nou. Conducătorul lor adjunct, Venkat Raj, nu a fost disponibil pentru a răspunde de ce alte setări din plugin elimină în tăcere JS pentru instrumentele de testare a performanței cu un clic pe un buton radio. Joe Miles, șeful de strategie al companiei, a împărtășit ultimele informații pe care le-a primit despre această problemă de la Venkat Raj:

„Setarea avansată folosită în acuzație este de fapt utilă pentru a afla dacă fișierele esențiale js/css încetinesc sau nu pagina web. Această caracteristică este în mod implicit, dezactivată și activată numai de utilizatori avansați care știu ce fac.

„Puteți folosi această funcție dacă aveți un script complet independent sau doriți să excludeți scripturi din testele de viteză a paginii (PageSpeed ​​Insights, GTMetrix...)

„Scripturile independente sunt, de exemplu, scripturile „analitice” sau „pixel”. Nu sunt necesare pentru ca site-ul web să funcționeze. „ Folosiți aceasta dacă aveți o foaie de stil complet independentă sau doriți să excludeți foile de stil din testele de viteză a paginii (PageSpeed ​​Insights, GTMetrix…) ”

Acest lucru este valabil pentru primul buton radio. Al doilea buton nu are nicio indicație că va dezactiva toate scripturile atunci când se utilizează instrumente de testare – nici echipa WP-Optimize nu pare să știe că este disponibil cu un clic pe un buton radio.

Miles nu a putut confirma dacă acesta este modul în care este intenționat să funcționeze sau dacă este o eroare. De asemenea, nu a putut explica de ce numele site-urilor populare de testare au fost ascunse în cod, dar a spus că dezvoltatorul original „nu funcționează pentru noi, deoarece este cod sursă deschis reutilizat din altă parte”.

„Cu toate acestea, credem că aceasta este o distragere a atenției de la acuzațiile false și ceea ce contează este că interfața de utilizare este foarte clară pentru setările, astfel încât utilizatorii să nu fie înșelați”, a spus Miles.

Raul Peixoto, autorul Fast Velocity Minify (FVM), pluginul din care WP-Optimize a copiat codul, a spus că poate confirma că acest cod face parte din FVM, dar a spus că nu a fost folosit în același mod:

Scopul unui astfel de cod pe FVM a fost complet diferit de cel de pe WP Optimize și, în plus, era necesar ca utilizatorii să activeze manual această opțiune prin wp-admin (era dezactivată implicit).

Scopul acelui cod a fost de a testa în mod selectiv impactul noilor scripturi sau plugin-uri în performanță și de a ajuta dezvoltatorii să decidă dacă ar trebui să refactorizeze, să elimine sau să înlocuiască plugin-uri sau script-uri grele.

Aceasta a existat pe FVM pentru a răspunde la întrebări ca acestea:
„Am un loc de producție și performanța mea este scăzută. Care ar fi performanța dacă acest plugin pur și simplu nu ar fi aici, dar fără a-l elimina încă de pe site pentru utilizatorii obișnuiți?”
„Care ar fi performanța dacă aș putea amâna toate scripturile sau anumite scripturi care nu sunt în prezent compatibile cu amânarea, înainte de a face efectiv această schimbare pentru toată lumea?”

O explicație oficială cu privire la utilizarea sa pe FVM este disponibilă pe forumul de asistență al pluginului începând din această dimineață.

„Presupun că dezvoltatorii angajați de WP Optimize nu au înțeles ce face acest lucru pe FVM sau în ce setări, sau poate că s-au simțit tentați să-l folosească ca un hack”, a spus Peixoto.

„De asemenea, ar trebui să ne amintim cu atenție că, la acea vreme, nu existau încă valori de web vitale disponibile public, așa că utilizarea așa ceva ar fi dat rezultate „măsurabile” mai bune, oferind astfel un avantaj de produs.”

Piexoto a spus că „s-a simțit obligat” să elimine acest cod în urmă cu doi ani din cauza cât de des a fost abuzat de dezvoltatorii care înșelau testele pentru clienții lor:

Mai repede înainte ceva timp și mi-am dat seama că unii dezvoltatori foloseau de fapt acest lucru pentru a înșela testele pentru clienții lor, așa că m-am simțit obligat să iau decizia cu privire la FVM 3 (deja la sfârșitul anului 2020) de a elimina această caracteristică, care a fost îndeplinită de un multe proteste ale dezvoltatorilor furioși când clienții lor au început să se plângă că scorurile lor au scăzut.

Am încercat în acel moment să explic că a avea un scor bun nu era același lucru cu a avea valori bune de web vitals, dar în cele din urmă am renunțat la asta, deoarece unii oameni le păsa mai mult de rezultatele testelor decât de performanța reală.

După lansarea FVM 3, practic îl întrețin și fac mici remedieri de erori atunci când sunt raportate, deoarece trebuie să mă concentrez pe alte lucruri. Am eliminat acea funcție și am remediat câteva erori care erau în așteptare la versiunea 3.2.9 și am împins o actualizare, așa că vă mulțumesc că mi-ați referit acest lucru.

Indiferent de motiv, UpdraftPlus a ales să îmbine acest cod în WP-Optimize în 2020 și, după cum sa raportat ieri, nu a mai atins codul de atunci.

Ceea ce părea a fi o problemă alb-negru ieri este o situație mai nuanțată. Implementarea codului FVM de către WP-Optimize este prost documentată în UI și induce în eroare cu privire la modul în care sunt încărcate scripturile. Poate determina proprietarii de site-uri să-l activeze fără a fi utilizatori avansați și, din punct de vedere istoric, are un potențial ridicat de abuz. Când Varghese a descoperit-o, l-a expus într-un mod inflamator, simțindu-se sigur că a găsit o faptă greșită din cauza cât de inexplicabil de înfundat este codul. Acest lucru a agravat problema, dar a început o conversație mai amplă și importantă.

Ar trebui utilizatorii să aibă acest tip de acces ușor (două clicuri) la dezactivarea scripturilor pentru instrumentele de testare a performanței? Cum pot dezvoltatorii din aceeași industrie să comunice mai bine despre potențialele daune pentru utilizatori pe care le văd în produsele altora? Ce fel de cerințe de documentare a codului ar trebui să implementeze agențiile pentru a preveni o situație ca aceasta în care codul trebuie investigat în decurs de câteva zile pentru a afla ce este intenționat să facă?