Falsche schnelle Websites: Wie man den Lighthouse-Score hackt

Die Web-Performance-Community lebt in einem trügerischen Zyklus. Menschen verwechseln den Lighthouse-Score mit der tatsächlichen Geschwindigkeit einer Website. Dies nutzen die Entwickler von Plugins aus, die darauf abzielen, diese Metrik zu verbessern, ohne die eigentliche Geschwindigkeit der Website zu erhöhen.

Es gibt viele Plugins auf dem Markt, die eine Beschleunigung der Website per Knopfdruck versprechen. Oft führen diese jedoch lediglich zu einer Verbesserung des Lighthouse-Scores.

Was erwartet Sie in diesem Artikel?

1. Gründe, warum der Lighthouse-Score uns Kopfschmerzen bereitet, anstatt die Geschwindigkeit zu messen.
2. Unschöne Verhaltensweisen des Plugins Website Speedy. Ein weiteres Puzzleteil zu den bereits bekannten fragwürdigen Praktiken der Plugins WP-Optimize und dem grenzwertigen Verhalten von WP Rocket.
3. Unsere Argumente, warum wir glauben, dass das Verzögern des Ladens sämtlichen JavaScripts eher ein Trick für den Lighthouse-Score ist als eine echte Optimierung.

Lassen Sie uns in das Problem eintauchen. Wir müssen beim Hauptschuldigen beginnen, dem Lighthouse-Score und seiner Wahrnehmung in der Laiengemeinschaft.

Webgeschwindigkeit? Das ist nicht der Lighthouse-Score. Punkt.

Lighthouse-Score. Eine schlechte Metrik, die aber alle interessiert#

Bei der Einführung von Kunden in PageSpeed.ONE spreche ich mehrmals im Monat mit jemandem, der das „Score in PageSpeed Insights verbessern“ möchte. Dieses kleine bunte Rädchen unten. Sie wissen schon, der Lighthouse-Score.

Wir verstehen das. Es ist eine einzige Zahl, hübsch bunt, leicht über Slack an Kollegen zu senden... Doch der Lighthouse-Score ist das Ergebnis eines synthetischen Tests einer Seite, in einer Umgebung, mit einer Einstellung. Zusammensetzung und Gewichtung können sich zwischen den Lighthouse-Versionen ändern. Ebenso zeigt Ihnen Lighthouse auf Ihrem Computer eine andere Zahl als Lighthouse in PageSpeed Insights.

Lassen Sie es uns noch einmal wiederholen:

Lighthouse-Score ist keine Metrik für die Webgeschwindigkeit. Es ist ein technischer Diagnoseindikator.

Die Webgeschwindigkeit entsteht nämlich nicht in Lighthouse. Sie entsteht auf den Telefonen Ihrer Besucher, im WLAN der Kneipe, auf einem alten chinesischen Smartphone mit drei Balken Empfang, mit zehn geöffneten Tabs und beim Klicken auf die Cookie-Leiste.

Lighthouse sieht das nicht. Es ist kein Benutzer. Lighthouse scrollt nicht, klickt nicht, meldet sich nicht an, öffnet keinen Produktfilter und geht nicht zum Checkout.

Die tatsächliche Geschwindigkeit wird von den Metriken Core Web Vitals aus der Chrome UX Report Datenbank gemessen. (Die Unterschiede zwischen Labordaten und Nutzerdaten werden in synth vs. CrUX vs. RUM zusammengefasst.)

Ein Ökonom würde sagen: „Klar, Goodharts Gesetz“#

Der Ökonom Charles Goodhart schrieb einst einen Satz, der heute an Universitäten gelehrt wird:

„Sobald eine Metrik zu einem Ziel wird, hört sie auf, eine gute Metrik zu sein.“

Das trifft hier perfekt zu. Genau das ist mit dem Lighthouse-Score passiert.

Die Leute wollen eine einfache Zahl. Google zeigt sie (meiner Meinung nach fälschlicherweise) in PageSpeed Insights groß und farbig an.

Kunden fragen Agenturen nach dem Lighthouse-Score. Einige Agenturen versprechen, ihn zu verbessern. Und dann kommen Plugins, die dasselbe versprechen, nur schneller und ohne Aufwand.

Sobald eine Diagnosenummer zu einem Verkaufsargument wird, entsteht ein Markt für deren Verbesserung. Und sobald die Berechnung vorhersehbar ist, beginnt jemand, die Metrik zu hacken, anstatt die Website zu optimieren.

Das Verzögern von JavaScript ist keine Optimierung, sondern das Verschieben des Problems#

Viele der heutigen „Beschleunigungs“-Plugins haben ein Häkchen, das den Lighthouse-Score in fünf Sekunden Arbeit um Dutzende von Punkten erhöhen kann. Sie verzögern das Ausführen von JavaScript, bis der Benutzer die erste Interaktion hat. Scrollen, Klicken, Berühren des Bildschirms.

Warum funktioniert das so zuverlässig, um den Lighthouse-Score zu hacken? Lighthouse lädt die Seite und misst. Es scrollt nicht, klickt nicht, berührt den Bildschirm nicht. Verzögertes JavaScript wird also im Test nie ausgeführt. Dadurch verschwinden z. B. der Total Blocking Time (TBT), die Metrik mit dem größten Gewicht im Lighthouse-Score, aus der Messung. Auch die Ladegeschwindigkeit (LCP) verbessert sich.

Der Lighthouse-Score schießt in die Höhe, während sich auf der Website nichts beschleunigt hat. Für den echten Nutzer hat sich nämlich nichts geändert. Es wurde nur auf später verschoben. Und oft zum schlechtesten möglichen Zeitpunkt.

Illustration des Verzögerns von JavaScript. Skripte werden erst nach einer Benutzerinteraktion geladen. Ein Übel.

Bei PageSpeed.ONE haben wir Hunderte von Websites optimiert, aber diese Technik nie unseren Kunden empfohlen. Welche Risiken birgt das Verzögern von JavaScript?

1. Negative Auswirkungen auf Interaktionen (INP). Der Benutzer kommt auf die Seite, liest die Überschrift und klickt. In diesem Moment wird das gesamte verzögerte JavaScript ausgeführt, das sich bis dahin angesammelt hat. Der Haupt-Thread des Browsers wird blockiert und der erste Klick des Benutzers wartet. Genau das kann die Metrik INP, die Google in die Core Web Vitals einbezieht, verschlechtern.
2. Negative Auswirkungen auf Layout-Verschiebungen (CLS). Skripte, die Inhalte nachträglich rendern, wie Karussells, Personalisierungen und andere, werden bei verzögertem JavaScript später ausgeführt. Im Lighthouse-Test wird keine Verschiebung gemessen, weil der Code nie ausgeführt wird. Den wahren Wert von CLS sehen Sie also nicht einmal.
3. Funktionalität der Messung. Analytik, Cookie-Zustimmungen, Chats, A/B-Tests und Konversionsmessungen werden zusammen mit allem anderen verzögert. Die Daten könnten dann nicht mehr stimmen und niemand weiß, warum.
4. Entwertung des Lighthouse-Scores. Wie wir bereits schrieben, ist der Lighthouse-Score zwar keine Metrik für Webgeschwindigkeit, aber nützlich für die Diagnose von Änderungen oder Optimierungen. Da im Lighthouse-Score kein JavaScript enthalten ist, messen Sie etwas völlig anderes als Ihre Website.

Das Verzögern von JavaScript ist eine schlechte Technik. Zu entscheiden, was wann und in welcher Reihenfolge geladen werden soll, ist Ingenieursarbeit, die Kenntnisse über die spezifische Website erfordert. Ein Häkchen, das sämtliches JavaScript verzögert, ersetzt diese Arbeit nicht.

Und das Problematischste zum Schluss: Die Anbieter dieser Funktionen geben in der Regel nirgendwo an, was das mit dem Lighthouse-Score macht und wie es die Geschwindigkeit für echte Nutzer gefährden kann. Würden sie das tun, würde der Kunde verstehen, dass er oft nicht eine schnellere Website kauft, sondern nur eine bessere Zahl im Test.

WP-Optimize: Der erwischte Lighthouse-Score-Optimierer#

Im Jahr 2022 veröffentlichte der Entwickler Gijo Varghese einen Screenshot des Plugins WP-Optimize, der zeigt, dass JavaScript auf der Seite nur geladen wird, wenn der Browser nicht Lighthouse, GTmetrix, Headless Chrome oder Pingdom ist.

In der Anzeige von WP-Optimize ist ein Code zu sehen, der versucht, Lighthouse, Pingdom oder GTmetrix zu erkennen.

Der Hersteller dieses WordPress-Optimierungs-Plugins hat die Vorwürfe öffentlich bestritten. Angeblich handelt es sich um eine spezifische Einstellung „Defer using JavaScript“.

Gut, aber warum gibt es diese Einstellung überhaupt? Wir sind wieder bei dem Punkt, dass ein solcher Aufbau kein Geschwindigkeitsoptimierer machen würde. Allgemeine Tipps zur Geschwindigkeit auf WordPress finden Sie in der WordPress-Optimierung.

WP Rocket: Die Grenze, wo die Optimierung endet#

Ein ähnliches Problem hat das bekannte Optimierungs-Plugin WP Rocket. Auch dieses enthält eine Funktion mit dem harmlosen Namen Delay JavaScript Execution. Sie aktivieren das Häkchen und alle Skripte warten, bis der Benutzer die Seite scrollt, klickt oder den Bildschirm berührt.

Details schrieb bereits im Jahr 2021 Alexander Goller in einem Artikel, in dem er dieses Problem zu Recht mit dem Abgasskandal von Dieselgate vergleicht, bei dem Volkswagen-Fahrzeuge die Motoreinstellungen bei Emissionstests änderten, um die geforderten Werte zu erfüllen.

Wie ist der Stand heute? Diese Einstellung existiert in WP Rocket immer noch. WP Rocket schreibt auf der Seite zur Einstellung des Verzögerns von JavaScript nur, dass es sich um eine der leistungsstärksten Optimierungen handelt.

Ein harmloses Plugin-Setting? Ich denke nicht. Auf der Funktionsseite erwähnt WP Rocket nämlich nicht, was dies mit dem Lighthouse-Score macht. Und das ist ein Problem.

WP Rocket spricht nur über die Vorteile der Einstellung „Delay JS execution“, erwähnt aber die Risiken nicht.

Sowohl WP-Optimize als auch WP Rocket verkaufen diese Funktion weiterhin, ohne darauf hinzuweisen, dass sie den Lighthouse-Score künstlich erhöhen kann und auf die weiteren Risiken, die ich oben beschrieben habe.

Website Speedy: Verbesserung der Geschwindigkeit oder des Lighthouse-Scores?#

Website Speedy ist ein Tool für verschiedene Plattformen, das von sich behauptet, ein „Automatischer Website-Geschwindigkeitsoptimierer“ zu sein. Einer unserer Kunden glaubte daran und nutzte dieses Add-on monatelang in dem Glauben, dass es die Webgeschwindigkeit verbessert.

Kollege Michal Matuška fand jedoch heraus, dass auch dieses Add-on nur den Lighthouse-Score künstlich erhöhen kann. Sehen Sie selbst.

Website Speedy verspricht auf der Homepage Einfluss auf die Absprungrate und SEO-Rankings.

Unsere Untersuchung zu Website Speedy#

Es beginnt schon auf der Website, wo „Einfluss auf Geschäftsmetriken“ und „Lighthouse-Score“ in einen Topf geworfen werden. Geschwindigkeit hat sicherlich Einfluss auf das Geschäft, aber das lässt sich nicht mit einer synthetischen Metrik verbinden.

Bereits das Marketing dieser Erweiterungen verlässt sich darauf, dass der Nutzer glaubt, der Lighthouse-Score sei die Webgeschwindigkeit. Und davon gibt es viele.

Die Autoren von Website Speedy geben in der Kommunikation mit uns zu:

„Our dashboards and documentation currently lead with lab scores, and we do not spell out that lab results can differ from what real users experience.“

Im Quellcode von Website Speedy fanden wir die Erkennung von Testwerkzeugen#

Kollege Michal ließ das Verhalten von Website Speedy keine Ruhe und wollte den Quellcode untersuchen. Dieser ist stark obfuskiert, also absichtlich unleserlich gemacht.

Im Code fanden wir nach der Dekodierung über mehrere KI-Agenten eine Bedingung, die entscheidet, ob JavaScript auf der Website überhaupt ausgeführt wird. Und was denken Sie? Ja, es wird nicht ausgeführt, wenn ein Geschwindigkeitstest erkannt wird.

Vor der Veröffentlichung fragten wir Website Speedy nach ihrer Haltung. Der Gründer Ishan Makkar antwortete sehr schnell:

„Our script does not detect or branch on Lighthouse, PageSpeed Insights, GTmetrix, headless browsers, or any synthetic testing environment.“

Er fügte hinzu, dass er den Code persönlich auf mehreren Kunden-Websites durchging und unsere Erkenntnisse nicht reproduzieren konnte. Er bot uns ein sauberes Demo mit seiner aktuellen Produktionsversion an, damit wir es selbst überprüfen können.

Das Demo kam am 18. August. Kollege Michal Matuška fand in seinem Skript Folgendes:

Ein Stück Code aus dem Demo von Website Speedy. Der Hack wurde vor uns versteckt.

Die Funktion heißt isAuditBot, also „ist es ein Audit-Bot“. Die erste Zeile gibt false zurück, sodass die gesamte Erkennung im Demo, das sie uns zur Verfügung gestellt haben, niemals durchgeführt wird. Im Skript von der Website unseres Kunden war sie nicht deaktiviert.

Übrigens, in dem toten Rest des Codes werden Strings getestet, die den Namen der häufigsten synthetischen Messwerkzeuge auffällig ähneln, also GTmetrix, Lighthouse, PageSpeed, WebPageTest und Headless Chrome.

Als Unschuldsbeweis erhielten wir eine Installation, in der die Erkennung von Testwerkzeugen auf die schnellstmögliche Weise entfernt wurde.

Was geschah, als wir Website Speedy auf der Kunden-Website ausschalteten?#

Mit dem Kunden vereinbarten wir, Website Speedy vorübergehend auszuschalten. So sehen wir ziemlich genau, was mit der Geschwindigkeit geschah, als das Plugin aufhörte zu funktionieren. Fast nichts.

Der Lighthouse-Score verschlechterte sich zwar drastisch…

Änderung des Lighthouse-Scores der Homepage nach dem Ausschalten von Website Speedy.

Nach dem Ausschalten von Website Speedy änderte sich der Lighthouse-Score auf der Homepage von 95 Punkten auf etwa 60. Hat er sich verschlechtert? Nein, er hat sich normalisiert.

Auf die Core Web Vitals hatte das Ausschalten des Plugins jedoch keinen Einfluss:

Entwicklung der Core Web Vitals nach dem Ausschalten des Plugins Website Speedy.

Wir sehen keine Veränderung, außer anderen Einflüssen, die auf der Website stattfinden:

• Eine leichte Verschlechterung der Webgeschwindigkeit (LCP) korreliert mit einer Schwankung TTFB (Response des Backends).
• CLS verbessert sich durch eine Anpassung einer anderen Eigenschaft der Website und steht zeitlich nicht im Zusammenhang.
• Es ist gut zu erwähnen, dass CrUX-Daten von Google einen 28-tägigen kumulativen Zustand zeigen, sodass sich Änderungen über einen längeren Zeitraum manifestieren.

Nach dem Ausschalten von Website Speedy kam es zur Normalisierung des Lighthouse-Scores auf der Website unseres Kunden. Aber die Geschwindigkeit der Website blieb unverändert.

Unsere Methodik und was wir nicht behaupten#

Um fair zu sein, sollten wir im Fall unserer Forschung zu Website Speedy unsere Methodik klären:

• Website Speedy wünscht keine Veröffentlichung des Quellcodes des Plugins, daher veröffentlichen wir nur den Quellcode des Demos, das sie uns zur Verfügung stellten und das sich vom Plugin-Quellcode unterscheidet.
• Wir experimentierten auf der Website eines unserer Kunden.
• Wir haben hier keine quantitativen Daten aus mehreren Projekten.
• Das Ausschalten des Plugins und unsere Untersuchung des Codes fanden im Juli 2026 statt.
• Außer dem Ausschalten des Plugins haben wir nichts Weiteres auf der Website optimiert.

Das Plugin Website Speedy hielt bei unserem Kunden den Lighthouse-Score hoch, ohne den Nutzern eine messbar schnellere Website zu bieten.

Ein Problem liegt also bei den Autoren der Plugins. Aber das größere ist bei den Nutzern selbst, die für diese Plugins zahlen.

Verwerfen Sie Lighthouse nicht. Machen Sie es nur nicht zum Ziel#

Verwenden Sie das Tool Lighthouse als Diagnose. Es findet Ihnen ein langsames Bild, ein unnötig großes JavaScript-Paket oder blockierendes CSS. Für diese Zwecke ist Lighthouse großartig.

Als Hauptgeschäftsmetriken für die Webgeschwindigkeit beobachten Sie Daten von echten Nutzern. Core Web Vitals aus dem Chrome UX Report oder Daten aus eigenen Messungen (RUM). Beobachten Sie die gesamte Domain und die wichtigsten Vorlagen im Monitoring, nicht nur eine URL einmalig.

Wir wissen, dass die Nachfrage nach einer einzigen Zahl für alles groß ist. In PageSpeed.ONE verwenden wir daher auch unser eigenes PageSpeed.ONE Score, das auf Nutzerdaten der Core Web Vitals basiert.

In unserem einmaligen Test der Webgeschwindigkeit rücken wir auch das Lighthouse-Score in den Hintergrund, so weit es geht. Stattdessen zeigen wir den Trend der Core Web Vitals und eine verbale Bewertung des Geschwindigkeitszustands.

Wenn Sie einen ähnlichen Fall selbst überprüfen möchten, hilft der folgende Ansatz.

Wie man einen verdächtigen Sprung im Lighthouse-Score überprüft#

Checkliste, um verdächtiges Hacken des Lighthouse-Scores aufzudecken:

• Beginnen Sie mit der Frage, ob das Score verdächtig schnell nach der Installation eines Plugins oder nach einer Konfigurationsänderung gestiegen ist.
• Vergleichen Sie die Netzwerk-Anfragen und ausgeführten JavaScripts in Lighthouse mit einem normalen Laden im Browser.
• Überprüfen Sie den ersten Scroll, Klick, die Cookie-Leiste, die Öffnung eines Filters, das Formular und den Checkout. Lighthouse scrollt und klickt nicht, aber der Benutzer tut es.
• Überprüfen Sie die Nutzerdaten (CrUX oder RUM) vor und nach der Änderung. Ein grüneres Laborscore ohne Verbesserung der Nutzerdaten ist kein Gewinn.
• Und vor allem: Kaufen Sie keine Plugins, die eine wundersame Beschleunigung mit einem Klick versprechen.

Wenn Ihnen das nächste Mal jemand ein Plugin anbietet, das das Score in fünf Minuten wundersam erhöht, fragen Sie ihn nach einer Sache:

Welchen Einfluss hat es auf die tatsächliche Geschwindigkeit bei Benutzern, zum Beispiel auf die Core Web Vitals? Wenn er Ihnen darauf nicht antworten kann, kennen Sie die Antwort selbst.

Halten Sie Ihre Websites schnell. Und messen Sie die Geschwindigkeit richtig.

Tags:Web PerformanceLighthouse