WP-Optimize bestreitet Vorwürfe des Betrugs von Performance-Tools

Gestern haben wir Vorwürfe von Gijo Varghese gegen UpdraftPlus, die Macher von WP-Optimize, veröffentlicht. Varghese ist Gründer von FlyingProxy, einem konkurrierenden Unternehmen, und bezeichnet sich selbst als „Performance-Enthusiasten“. Er warf dem Plugin vor, „Pagespeed und andere Tools zu betrügen“, indem es verhinderte, dass JavaScript-Dateien geladen wurden, wenn Benutzer ihre Websites mit beliebten Leistungstest-Tools testeten. Der Code verwendet einen seltsamen Satz verschleierter Namen für die Testwerkzeuge, was seinen Verdacht weckte.

Varghese versäumte es in seinem Tweet zu erwähnen, dass dies passiert, wenn eine der Einstellungen des Plugins unter Minify > JS so eingestellt ist, dass JavaScript zurückgestellt wird. Es gibt zwei Optionsfeldeinstellungen, aber sie sind verwirrend.

Das erste Optionsfeld ermöglicht es Benutzern, ausgewählte JavaScript-Dateien zurückzustellen. Es sagt, dass die Dateien asynchron geladen werden (nicht dasselbe wie defer), und dann sagt es auch, dass Benutzer das erste Optionsfeld auswählen sollten, wenn sie Skripte von Seitengeschwindigkeitstests ausschließen möchten. Es ist nicht klar, wie die Skripte für den Benutzer oder für Testseiten geladen werden. Ausschließen ist nicht dasselbe wie Zurückstellen, daher ist die Benutzeroberfläche der Einstellungen in diesem Fall etwas irreführend und sollte klarer sein.

Die zweite Radiooption ist für Benutzer gedacht, die einfach alles JavaScript zurückstellen möchten. Wenn man „Defer using JavaScript (Use this method if you require support for old browsers)“ auswählt, sollte es genau das tun, was im Link beschrieben wird:

Wenn das defer -Attribut gesetzt ist, gibt es an, dass das Skript parallel zum Parsen der Seite heruntergeladen und ausgeführt wird, nachdem die Seite das Parsen beendet hat.

Obwohl die Benutzeroberfläche sagt, dass alle Dateien zurückgestellt werden, lädt WP-Optimize niemals das JavaScript für Leistungstestseiten. Bei dieser zweiten Option erfolgt der Ausschluss von Testseiten ohne Zustimmung des Benutzers. Wenn Benutzer das gewollt hätten, hätten sie das vorherige Optionsfeld ausgewählt und explizit angegeben, welche Skripte ausgeschlossen werden sollen.

Varghese ließ einige wichtige Details in seinem ursprünglichen Bericht aus, aber er war insofern zutreffend, als bestimmte Einstellungen irreführend darüber sind, was sie tatsächlich tun. Er demonstrierte dies in einem Folgevideo, in dem keine manuelle Eingabe von auszuschließenden Skripten erfolgt und die zweite Funkoption aktiviert ist.

„Sie bieten Benutzern die Möglichkeit, Testwerkzeuge zu betrügen“, sagte Varghese. „Außerdem zeigt die Verwendung von Namen wie „ighth“ für Lighthouse und „tmetr“ für GTmetrix deutlich, was sie zu tun versuchen.

„Die meisten Benutzer versuchen, verschiedene Funktionen zu deaktivieren und zu aktivieren, um zu sehen, welche die Geschwindigkeit/Ergebnisse in Testtools erhöhen.“

Varghese behauptet, dass es keine Notwendigkeit gibt, die Dinge beim Testen von Tools und Menschen anders zu machen, da dies für Websitebesitzer verwirrend sein kann. Seine Behauptung ließ wichtige Details aus und implizierte, dass all dies im Code versteckt sei. Es ist für eine der Einstellungen, aber nicht für die andere. Die Schnittstelle impliziert, dass Sie Skripte manuell eingeben müssen, um sie vom Testen auszuschließen, aber auch dies ist irreführend.

WP-Optimize hat heute eine öffentliche Antwort auf die Vorwürfe veröffentlicht, aber keines der Ergebnisse der von ihnen abgeschlossenen Code-Untersuchung offengelegt. Stattdessen zitierte das Unternehmen ein Video von Peter Wilkinson von Divi Engine, der behauptet, dass Benutzer Skripte manuell eingeben müssen, damit Testseiten sie ausschließen.

Wilkinson wird mit der Schlussfolgerung zitiert, dass „Gijo Varghese Täuschung verwendet hat, um Flying Pages und Flying Press zu fördern“, indem er dieses Problem auf Twitter öffentlich bekannt machte.

„Tatsächlich (nach meinen Recherchen) „betrug“ WP-Optimize keine Pagespeed-Tools, wenn Sie Ihr JavaScript installieren oder minimieren“, sagte Wilkinson.

„Um die Tools zu „betrügen“, müssen Sie die JS-Dateien, die Sie asynchron laden möchten, manuell zu einer Einstellung hinzufügen, die eindeutig die Bezeichnung „Verwenden Sie dies, wenn Sie ein völlig unabhängiges Skript haben oder Skripte von Seitengeschwindigkeitstests ausschließen möchten ( PageSpeed ​​Insights, GTMetrix…)'“

Das ist nicht der Fall. Der einfachste Weg zum Testen besteht darin, das Plugin zu installieren, „JavaScript zurückstellen“ zu aktivieren und dann die Quelle anzuzeigen, um zu sehen, dass Leistungstools ausgeschlossen sind.

Da die öffentliche Antwort von WP-Optimize auf das Problem nichts aus ihrer Code-Untersuchung enthielt, habe ich sie erneut kontaktiert. Ihr stellvertretender Leiter Venkat Raj war nicht verfügbar, um zu beantworten, warum andere Einstellungen im Plugin JS stillschweigend für Leistungstest-Tools mit einem Klick auf ein Optionsfeld entfernen. Joe Miles, Leiter der Strategie des Unternehmens, teilte die letzten Informationen mit, die er von Venkat Raj zu diesem Thema erhalten hatte:

„Die in der Behauptung verwendete erweiterte Einstellung ist tatsächlich nützlich, um herauszufinden, ob die wesentlichen js/css-Dateien die Webseite tatsächlich verlangsamen oder nicht. Diese Funktion ist standardmäßig deaktiviert und wird nur von erfahrenen Benutzern aktiviert, die wissen, was sie tun.

„Sie können diese Funktion verwenden, wenn Sie ein völlig unabhängiges Skript haben oder Skripte von Seitengeschwindigkeitstests ausschließen möchten (PageSpeed ​​Insights, GTMetrix…)

„Unabhängige Skripte sind beispielsweise ‚Analytics‘- oder ‚Pixel‘-Skripte. Sie sind nicht erforderlich, damit die Website funktioniert. ' Verwenden Sie dies, wenn Sie ein völlig unabhängiges Stylesheet haben oder Stylesheets von Seitengeschwindigkeitstests ausschließen möchten (PageSpeed ​​Insights, GTMetrix…) '

Dies gilt für das erste Optionsfeld. Die zweite Schaltfläche hat keinen Hinweis darauf, dass sie alle Skripte abschaltet, wenn Testtools verwendet werden – und dem Team von WP-Optimize scheint auch nicht bewusst zu sein, dass sie mit einem Klick auf eine Optionsschaltfläche verfügbar ist.

Miles konnte nicht bestätigen, ob dies so funktionieren soll oder ob es sich um einen Fehler handelt. Er konnte auch nicht erklären, warum die Namen der beliebten Testseiten im Code verschleiert wurden, sagte aber, dass der ursprüngliche Entwickler „für uns nicht funktioniert, da es sich um Open-Source-Code handelt, der von woanders umfunktioniert wurde“.

„Wir glauben jedoch, dass dies von den falschen Anschuldigungen ablenkt, und was zählt, ist, dass die Benutzeroberfläche für die Einstellungen sehr klar ist, damit die Benutzer nicht getäuscht werden“, sagte Miles.

Raul Peixoto, Autor von Fast Velocity Minify (FVM), dem Plugin, von dem WP-Optimize den Code kopiert hat, sagte, er könne bestätigen, dass dieser Code Teil von FVM war, sagte aber, dass er nicht auf die gleiche Weise verwendet wurde:

Der Zweck eines solchen Codes auf FVM war völlig anders als der auf WP Optimize und außerdem mussten die Benutzer diese Option manuell über wp-admin aktivieren (sie war standardmäßig deaktiviert).

Der Zweck dieses Codes bestand darin, die Auswirkungen neuer Skripte oder Plugins auf die Leistung selektiv zu testen und Entwicklern bei der Entscheidung zu helfen, ob sie umfangreiche Plugins oder Skripte umgestalten, entfernen oder ersetzen sollten.

Dies existierte auf FVM, um Fragen wie diese zu beantworten:
„Ich habe eine Produktionsstätte und meine Leistung ist gering. Wie wäre die Leistung, wenn dieses Plugin einfach nicht da wäre, aber ohne es tatsächlich von der Seite für normale Benutzer zu entfernen?“
"Wie wäre die Leistung, wenn ich alle Skripte oder bestimmte Skripte, die derzeit nicht mit der Verzögerung kompatibel sind, zurückstellen könnte, bevor ich diese Änderung tatsächlich für alle vornehme?"

Eine offizielle Erklärung zur Verwendung auf FVM ist seit heute Morgen im Support-Forum des Plugins verfügbar.

„Ich nehme an, dass die von WP Optimize eingestellten Entwickler nicht verstanden haben, was das auf FVM macht oder unter welchen Einstellungen, oder vielleicht fühlten sie sich versucht, es als Hack zu verwenden“, sagte Peixoto.

„Wir sollten auch sorgfältig bedenken, dass es zu dieser Zeit noch keine öffentlich verfügbaren Web-Vitals-Metriken gab, sodass die Verwendung von so etwas zu besseren ‚messbaren‘ Ergebnissen geführt und somit einen Produktvorteil geboten hätte.“

Piexoto sagte, er habe sich „gezwungen gefühlt“, diesen Code vor zwei Jahren zu entfernen, weil er oft von Entwicklern missbraucht wurde, die bei Tests für ihre Kunden betrogen haben:

Einige Zeit vorspulen, und mir wurde klar, dass einige Entwickler dies tatsächlich nutzten, um bei den Tests für ihre Kunden zu schummeln, also fühlte ich mich gezwungen, die Entscheidung für FVM 3 (bereits Ende 2020) zu treffen, diese Funktion zu entfernen, was von einem erfüllt wurde viele Proteste von verärgerten Entwicklern, als ihre Kunden anfingen, sich darüber zu beschweren, dass ihre Punktzahlen gesunken sind.

Ich habe damals versucht zu erklären, dass eine gute Punktzahl nicht dasselbe ist wie gute Web-Vitals-Metriken, aber irgendwann habe ich das aufgegeben, da sich einige Leute mehr um die Testergebnisse als um die tatsächliche Leistung gekümmert haben.

Nach der Veröffentlichung von FVM 3 warte ich im Grunde nur darauf und behebe kleine Fehler, wenn sie gemeldet werden, da ich mich auf andere Dinge konzentrieren muss. Ich habe diese Funktion entfernt und ein paar Fehler behoben, die in Version 3.2.9 anhängig waren, und ein Update veröffentlicht, also danke, dass Sie mich darauf hingewiesen haben.

UpdraftPlus hat sich aus irgendeinem Grund dafür entschieden, diesen Code im Jahr 2020 in WP-Optimize einzufügen, und hat, wie gestern berichtet, den Code seitdem nicht mehr angerührt.

Was gestern wie ein Schwarz-Weiß-Problem aussah, ist eine differenziertere Situation. Die Implementierung des FVM-Codes durch WP-Optimize ist in der Benutzeroberfläche schlecht dokumentiert und führt in die Irre, wie die Skripte geladen werden. Es kann Websitebesitzer dazu bringen, es zu aktivieren, ohne fortgeschrittene Benutzer zu sein, und hat historisch gesehen ein hohes Missbrauchspotenzial. Als Varghese es entdeckte, enthüllte er es auf aufrührerische Weise und war sich sicher, dass er ein Fehlverhalten gefunden hatte, weil der Code unerklärlicherweise verschleiert war. Dies verschärfte das Problem, begann aber ein breiteres, wichtiges Gespräch.

Sollten Benutzer einen so einfachen Zugriff (zwei Klicks) haben, um Skripts für Leistungstest-Tools zu deaktivieren? Wie können Entwickler in der gleichen Branche besser über potenzielle Schäden für Benutzer kommunizieren, die sie in den Produkten anderer sehen? Welche Art von Code-Dokumentationsanforderungen sollten Behörden implementieren, um eine Situation wie diese zu vermeiden, in der Code über Tage hinweg untersucht werden muss, um herauszufinden, was er tun soll?