WP-Optimize zaprzecza zarzutom oszukiwania narzędzi wydajnościowych

Wczoraj opublikowaliśmy zarzuty Gijo Varghese przeciwko UpdraftPlus, twórcom WP-Optimize. Varghese jest założycielem FlyingProxy, konkurencyjnej firmy i identyfikuje się jako „entuzjasta wydajności”. Oskarżył wtyczkę o „oszukiwanie Pagespeed i innych narzędzi” poprzez ukrywanie plików JavaScript przed ładowaniem, gdy użytkownicy testują swoje witryny za pomocą popularnych narzędzi do testowania wydajności. Kod wykorzystuje dziwny zestaw zaciemnionych nazw narzędzi testowych, co wzbudziło jego podejrzenia.

Varghese nie wspomniał w swoim tweecie, że dzieje się tak, gdy jedno z ustawień wtyczki w Minify > JS jest ustawione na odroczenie JavaScript. Istnieją dwa ustawienia przycisków radiowych, ale są mylące.

Pierwszy przycisk opcji umożliwia użytkownikom odroczenie wybranych plików JavaScript. Mówi, że pliki będą ładowane asynchronicznie (nie to samo, co odroczenie), a także mówi, że użytkownicy powinni wybrać pierwszy przycisk opcji, jeśli chcą wykluczyć skrypty z testów szybkości strony. Nie jest jasne, w jaki sposób skrypty zostaną załadowane dla użytkownika lub dla witryn testowych. Wykluczanie to nie to samo, co odroczenie, więc w tym przypadku interfejs ustawień jest nieco mylący i powinien być bardziej przejrzysty.

Druga opcja radiowa jest przeznaczona dla użytkowników, którzy po prostu chcą odłożyć cały JavaScript. Jeśli ktoś wybierze „Odrocz za pomocą JavaScript (Użyj tej metody, jeśli potrzebujesz obsługi starszych przeglądarek)” , powinien zrobić dokładnie to, co opisuje w linku:

Jeśli atrybut defer jest ustawiony, oznacza to, że skrypt jest pobierany równolegle z analizowaniem strony i wykonywany po zakończeniu analizowania strony.

Mimo że interfejs użytkownika mówi, że odracza wszystkie pliki, WP-Optimize nigdy nie ładuje JavaScript do witryn testowania wydajności. W tej drugiej opcji wykluczenie witryn testowych odbywa się bez zgody użytkowników. Gdyby użytkownicy tego chcieli, wybraliby poprzedni przycisk opcji i wyraźnie określili, które skrypty mają zostać wykluczone.

Varghese pominął kilka istotnych szczegółów w swoim pierwotnym raporcie, ale było to dokładne, ponieważ pewne ustawienia wprowadzają w błąd co do tego, co faktycznie robią. Zademonstrował to w kolejnym filmie wideo, w którym nie ma ręcznego wprowadzania żadnych skryptów do wykluczenia, a druga opcja radiowa jest zaznaczona.

„Dają użytkownikom możliwość oszukiwania narzędzi testowych” – powiedział Varghese. „Ponadto używanie nazw takich jak „ósma” dla Lighthouse i „tmetr” dla GTmetrix wyraźnie pokazuje, co próbują zrobić.

„Większość użytkowników próbuje wyłączyć i włączyć różne funkcje, aby zobaczyć, która z nich zwiększa prędkość / wyniki w narzędziach testowych”.

Varghese twierdzi, że nie ma potrzeby robić rzeczy inaczej w przypadku narzędzi testowych i ludzi, ponieważ może to być mylące dla właścicieli witryn. Jego zarzut pominął istotne szczegóły i sugerował, że wszystko to jest ukryte w kodzie. To jest dla jednego z ustawień, ale nie dla drugiego. Interfejs sugeruje, że musisz ręcznie wprowadzać skrypty, aby wykluczyć je z testowania, ale jest to również mylące.

WP-Optimize opublikowała dziś publiczną odpowiedź na zarzuty, ale nie ujawniła żadnych wyników z przeprowadzonego przez nich dochodzenia w sprawie kodu. Zamiast tego firma powołała się na film stworzony przez Petera Wilkinsona z Divi Engine, który twierdzi, że użytkownicy muszą ręcznie wprowadzać skrypty, aby witryny testowe ich wykluczały.

Wilkinson jest cytowany jako konkludujący, że „Gijo Varghese użył oszustwa, aby promować Flying Pages i Flying Press”, aby zwrócić uwagę opinii publicznej na ten problem na Twitterze.

„W rzeczywistości (z moich badań) WP-Optimize nie„ oszukuje ”narzędzi Pagespeed podczas instalacji lub minimalizacji kodu JavaScript” – powiedział Wilkinson.

„Aby „oszukać” narzędzia, musisz ręcznie dodać pliki JS, które chcesz ładować asynchronicznie, do ustawienia, które wyraźnie ma etykietę „Użyj tego, jeśli masz całkowicie niezależny skrypt lub chcesz wykluczyć skrypty z testów szybkości strony ( PageSpeed ​​Insights, GTMetrix…)'”

Nie o to chodzi. Najłatwiejszym sposobem przetestowania jest zainstalowanie wtyczki, włączenie „odroczenia całego JavaScript”, a następnie wyświetlenie źródła, aby zobaczyć, czy narzędzia wydajnościowe są wykluczone.

Ponieważ publiczna odpowiedź WP-Optimize na ten problem nie obejmowała niczego z ich dochodzenia w sprawie kodu, skontaktowałem się z nimi ponownie. Ich zastępca, Venkat Raj, nie był w stanie odpowiedzieć, dlaczego inne ustawienia wtyczki po cichu usuwają JS dla narzędzi do testowania wydajności jednym kliknięciem przycisku. Joe Miles, szef strategii firmy, podzielił się ostatnimi informacjami, jakie otrzymał w tej sprawie od Venkata Raja:

„Zaawansowane ustawienie użyte w oskarżeniu jest rzeczywiście przydatne, aby dowiedzieć się, czy podstawowe pliki js/css rzeczywiście spowalniają stronę internetową, czy nie. Ta funkcja jest domyślnie wyłączona i włączana tylko przez zaawansowanych użytkowników, którzy wiedzą, co robią.

„Możesz użyć tej funkcji, jeśli masz całkowicie niezależny skrypt lub chcesz wykluczyć skrypty z testów szybkości strony (PageSpeed ​​Insights, GTMetrix…)

„Niezależne skrypty to na przykład skrypty „analityczne” lub „pikselowe”. Nie są one wymagane do działania serwisu. ' Użyj tego, jeśli masz całkowicie niezależny arkusz stylów lub chcesz wykluczyć arkusze stylów z testów szybkości strony (PageSpeed ​​Insights, GTMetrix…) '

Dotyczy to pierwszego przycisku opcji. Drugi przycisk nie wskazuje, że wyłączy wszystkie skrypty podczas korzystania z narzędzi testowych – ani zespół WP-Optimize nie wydaje się być świadomy, że jest dostępny po kliknięciu przycisku opcji.

Miles nie mógł potwierdzić, czy tak ma działać, czy też jest to błąd. Nie mógł również wyjaśnić, dlaczego nazwy popularnych witryn testowych zostały zaciemnione w kodzie, ale powiedział, że oryginalny programista „nie działa dla nas, ponieważ jest to kod open source, który został wykorzystany gdzie indziej”.

„Uważamy jednak, że jest to odwrócenie uwagi od fałszywych zarzutów, a ważne jest to, że interfejs użytkownika jest bardzo przejrzysty dla ustawień, więc użytkownicy nie są oszukiwani” – powiedział Miles.

Raul Peixoto, autor Fast Velocity Minify (FVM), wtyczki, z której WP-Optimize skopiował kod, powiedział, że może potwierdzić, że ten kod był częścią FVM, ale powiedział, że nie był używany w ten sam sposób:

Cel takiego kodu na FVM był zupełnie inny niż ten na WP Optimize, a ponadto wymagał od użytkowników ręcznego włączenia tej opcji przez wp-admin (domyślnie była wyłączona).

Celem tego kodu było selektywne testowanie wpływu nowych skryptów lub wtyczek na wydajność i pomoc programistom w podjęciu decyzji, czy powinni dokonać refaktoryzacji, usunięcia lub zastąpienia ciężkich wtyczek lub skryptów.

To istniało w FVM, aby odpowiedzieć na takie pytania:
„Mam zakład produkcyjny i moja wydajność jest niska. Jaka byłaby wydajność, gdyby tej wtyczki po prostu nie było, ale bez faktycznego usunięcia jej ze strony dla zwykłych użytkowników?”
„Jaka byłaby wydajność, gdybym mógł odroczyć wszystkie skrypty lub konkretne skrypty, które nie są obecnie kompatybilne z odroczeniem, zanim faktycznie dokonam tej zmiany dla wszystkich?”

Oficjalne wyjaśnienie dotyczące jego użycia na FVM jest dostępne na forum wsparcia wtyczki od dzisiejszego ranka.

„Przypuszczam, że programiści zatrudnieni przez WP Optimize nie rozumieli, co to robi na FVM ani w jakich ustawieniach, a może poczuli pokusę, aby użyć go jako hacka” – powiedział Peixoto.

„Powinniśmy również uważnie pamiętać, że w tamtym czasie nadal nie było publicznie dostępnych wskaźników dotyczących statystyk internetowych, więc użycie czegoś takiego przyniosłoby lepsze „mierzalne” wyniki, oferując w ten sposób przewagę produktu”.

Piexoto powiedział, że „czuł się zmuszony” do usunięcia tego kodu dwa lata temu z powodu tego, jak często był on nadużywany przez programistów, którzy oszukiwali w testach dla swoich klientów:

Szybko do przodu i zdałem sobie sprawę, że niektórzy programiści faktycznie używają tego do oszukiwania w testach dla swoich klientów, więc poczułem się zmuszony do podjęcia decyzji w sprawie FVM 3 (już pod koniec 2020 r.) o usunięciu tej funkcji, co zostało spełnione przez wiele protestów wściekłych programistów, gdy ich klienci zaczęli narzekać, że ich wyniki spadły.

Próbowałem wtedy wytłumaczyć, że dobry wynik to nie to samo, co dobre wskaźniki Web Vitals, ale ostatecznie zrezygnowałem z tego, ponieważ niektórzy ludzie bardziej interesowali się wynikami testów niż rzeczywistą wydajnością.

Po wydaniu FVM 3 zasadniczo tylko go utrzymuję i naprawiam drobne błędy po zgłoszeniu, ponieważ muszę skupić się na innych rzeczach. Usunąłem tę funkcję i naprawiłem kilka błędów, które były w toku w wersji 3.2.9, i wypchnąłem aktualizację, więc dziękuję za skierowanie do mnie tego.

Z jakiegoś powodu UpdraftPlus zdecydował się na połączenie tego kodu z WP-Optimize w 2020 roku i, jak doniesiono wczoraj, od tego czasu nie dotknął kodu.

To, co wczoraj wydawało się czarno-białe, jest bardziej zniuansowaną sytuacją. Implementacja kodu FVM przez WP-Optimize jest słabo udokumentowana w interfejsie użytkownika i wprowadza w błąd co do sposobu ładowania skryptów. Może prowadzić właścicieli witryn do jej aktywacji bez bycia zaawansowanymi użytkownikami i historycznie ma wysoki potencjał nadużyć. Kiedy Varghese go odkrył, zdemaskował go w podburzający sposób, czując się pewien, że znalazł coś złego z powodu tego, jak niewytłumaczalnie zaciemniony jest kod. To pogłębiło problem, ale zapoczątkowało szerszą, ważną rozmowę.

Czy użytkownicy powinni mieć tak łatwy dostęp (dwa kliknięcia) do wyłączania skryptów dla narzędzi do testowania wydajności? W jaki sposób programiści z tej samej branży mogą lepiej informować użytkowników o potencjalnych szkodach, które widzą w produktach innych osób? Jakie wymagania dotyczące dokumentacji kodu powinny wdrożyć agencje, aby zapobiec takim sytuacjom, w których kod musi być badany przez kilka dni, aby dowiedzieć się, do czego ma służyć?