Scheinbar schnelle Websites: Wie das Lighthouse-Score gehackt wird

Die Web-Performance-Community steckt in einem falschen Kreislauf. Leute verwechseln nämlich das Lighthouse-Score mit der tatsächlichen Webgeschwindigkeit. Das nutzen Plugin-Autoren aus, die darauf abzielen, diese Metrik zu verbessern, ohne die Webgeschwindigkeit wirklich zu steigern.

Auf dem Markt gibt es zahlreiche Plugins, die eine Beschleunigung der Website per Knopfdruck versprechen. Wir nennen hier beispielhaft WP-Optimize, WP Rocket oder Website Speedy. Ihr Effekt ist jedoch oft nur eine Verbesserung des Lighthouse-Scores.

Dies geschieht meist durch das Verzögern des Ladens von JavaScript. Dadurch kann eine Metrik verbessert werden, aber andere Geschwindigkeitsmetriken werden verschlechtert und Ihre Analytik könnte beschädigt werden.

Website Speedy haben wir im Rahmen eines Experiments bei einem Kunden genauer untersucht und festgestellt, dass das Deaktivieren des Plugins zwar das Lighthouse-Score auf normale Werte zurückbringt, aber nichts an der Webgeschwindigkeit ändert.

Zudem beobachten wir eine sehr verdächtige Erkennung von Tests, sodass sich eine mit Lighthouse getestete Website anders verhalten kann als bei echten Nutzern.

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

Beim Onboarding von Kunden in PageSpeed.ONE spreche ich mehrmals im Monat mit jemandem, der das „Score in PageSpeed Insights“ verbessern möchte. Dieses nette, farbige Rädchen, Sie wissen schon, das Lighthouse-Score.

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

Lassen Sie uns das nochmals wiederholen:

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

Schauen Sie auch in PageSpeed Insights an die falsche Stelle?

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

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

Die tatsächliche Geschwindigkeit messen die Metriken Core Web Vitals aus der Datenbank des Chrome UX Report. (Die Unterschiede zwischen Labor und Nutzerdaten fasst synth vs. CrUX vs. RUM zusammen.)

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.“

Hier passt das perfekt. 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 bunt an.

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

Sobald aus einer Diagnosezahl ein 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.

JavaScript-Verzögerung ist keine Optimierung, sondern eine Problemverlagerung#

Eine große Anzahl heutiger „Beschleunigungs“-Plugins hat ein Kästchen, das das Lighthouse-Score um Dutzende Punkte in fünf Sekunden Arbeit erhöhen kann. Es verzögert das Ausführen des gesamten JavaScripts bis zur ersten Interaktion des Nutzers. Scrollen, Klicken, Berühren des Bildschirms.

Warum funktioniert das so zuverlässig, um das Lighthouse-Score zu hacken? Lighthouse lädt und misst die Seite. Es scrollt nicht, klickt nicht, berührt den Bildschirm nicht. Der verzögerte JavaScript-Code wird im Test also nie ausgeführt. Aus der Messung verschwinden dadurch zum Beispiel der Total Blocking Time (TBT), eine Metrik, die im Lighthouse-Score das meiste Gewicht hat. Auch die Ladegeschwindigkeit (LCP) verbessert sich.

Das Lighthouse-Score schnellt nach oben, dabei hat sich auf der Website nichts beschleunigt. Für den echten Nutzer hat sich nämlich nichts geändert. Es wurde nur auf später verschoben. Und oft in den ungünstigsten Moment.

Illustration der JavaScript-Verzögerung. Skripte laden erst nach einer Nutzerinteraktion. Es ist böse.

Bei PageSpeed.ONE haben wir hunderte Websites optimiert, aber diese Technik nie unseren Kunden empfohlen. Welche Risiken birgt die Verzögerung aller JavaScripts?

1. Negativer Einfluss auf Interaktionen (INP). Der Nutzer 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 Hauptthread des Browsers wird blockiert und der erste Klick des Nutzers wartet. Genau das kann die Metrik INP verschlechtern, die Google in die Core Web Vitals einbezieht.
2. Negativer Einfluss auf Layoutverschiebungen (CLS). Skripte, die Inhalte rendern, also Karussells, Personalisierungen und andere, starten bei JavaScript-Verzögerung zu spät. Im Lighthouse-Test wird keine Verschiebung gemessen, weil der Code nie ausgeführt wurde. Den tatsächlichen Wert von CLS sehen Sie also nicht einmal.
3. Funktionalität der Messung. Analytik, Cookie-Zustimmung, Chat, A/B-Tests und Konversionsmessungen werden zusammen mit allem anderen verzögert. Die Daten könnten dann nicht übereinstimmen und niemand weiß warum.
4. Entwertung des Lighthouse-Scores. Wie wir geschrieben haben, ist das Lighthouse-Score zwar keine Metrik für die Webgeschwindigkeit, aber für die Diagnose von Änderungen oder Optimierungen nützlich. Indem im Lighthouse-Score kein JavaScript enthalten ist, messen Sie etwas völlig anderes als Ihre Website.

Die Verzögerung aller JavaScripts ist eine schlechte Technik. Zu entscheiden, was wann und in welcher Reihenfolge geladen werden soll, ist eine Ingenieursarbeit, die das Wissen über die spezifische Website erfordert. Ein Kästchen, das den gesamten 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 bei echten Nutzern gefährden kann. Wenn sie das nämlich angäben, würde der Kunde verstehen, dass er oft nicht eine schnellere Website kauft, sondern nur eine bessere Zahl im Test.

WP-Optimize: erwischter Optimierer des Lighthouse-Scores#

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 WP-Optimize-Demo ist Code zu sehen, der versucht, Lighthouse, Pingdom oder GTmetrix zu erkennen.

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

Gut, aber warum gibt es diese Einstellung überhaupt? Wir sind wieder da, dass ein solcher Aufbau kein Geschwindigkeitsoptimierer macht. Allgemeine Tipps zur Geschwindigkeit bei WordPress haben wir in der WordPress-Optimierung.

WP Rocket: Die Grenze, wo die Optimierung endet#

Ein ähnliches Problem hat auch das bekannte Optimierungsplugin WP Rocket. Auch dieses enthält eine Funktion mit dem harmlos klingenden Namen Delay JavaScript Execution. Sie aktivieren ein Kästchen und alle Skripte warten, bis der Nutzer die Seite scrollt, klickt oder den Bildschirm berührt.

Details schrieb schon im Jahr 2021 Alexander Goller in einem Artikel, in dem er dieses Problem zu Recht mit dem Dieselgate-Emissionsskandal vergleicht, bei dem Volkswagen-Autos die Motoreinstellungen bei Emissionstests änderten, um die erforderlichen Werte zu erfüllen.

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

Ein unschuldiges Plugin-Einstellung? Ich denke nicht. Nirgendwo auf der Funktionsseite schreibt WP Rocket, was das mit dem Lighthouse-Score macht. Und das ist ein Problem.

WP Rocket schreibt nur über die Vorteile der Einstellung „Delay JS execution“, aber nicht über die Risiken.

Also verkaufen WP-Optimize und WP Rocket diese Funktion weiterhin, ohne darauf hinzuweisen, dass sie das Lighthouse-Score künstlich erhöhen und auf weitere 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 der Annahme, dass es der Webgeschwindigkeit hilft.

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

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

Unsere Recherche zu Website Speedy#

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

Der Marketing dieser Erweiterungen verlässt sich auf den Nutzer, der glaubt, dass das Lighthouse-Score die Webgeschwindigkeit ist. Und davon gibt es viele.

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

„Unsere Dashboards und Dokumentationen führen derzeit mit Laborscores, und wir machen nicht deutlich, dass Laborergebnisse von den Erfahrungen der realen Nutzer abweichen können.“

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 verschleiert, also absichtlich unverständlich gemacht.

Im Code fanden wir nach der Entschlüsselung ü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 es ein Geschwindigkeitstest erkannt wird.

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

„Unser Skript erkennt oder verzweigt sich nicht auf Lighthouse, PageSpeed Insights, GTmetrix, Headless-Browser oder irgendeine synthetische Testumgebung.“

Er fügte hinzu, dass er den Code auf mehreren Live-Kundenwebsites persönlich überprüft hat und unsere Ergebnisse nicht reproduzieren konnte. Und 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 darin 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-Roboter“. Die erste Zeile gibt false zurück, sodass sich im Demo, das uns zur Verfügung gestellt wurde, die gesamte Erkennung nie ausführt. Im Skript von der Website unseres Kunden war sie nicht deaktiviert.

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

Als Beweis der Unschuld bekamen wir eine Installation, in der die Erkennung von Testwerkzeugen auf die schnellste Art und Weise entfernt wurde.

Was passierte, als wir Website Speedy auf der Kundenwebsite deaktivierten?#

Mit dem Kunden einigten wir uns auf die vorübergehende Deaktivierung von Website Speedy. So sehen wir ziemlich genau, was mit der Geschwindigkeit passiert ist, als das Plugin nicht mehr funktionierte. Fast nichts.

Das Lighthouse-Score verschlechterte sich zwar drastisch...

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

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

Der Einfluss auf die Core Web Vitals war jedoch durch das Ausschalten des Plugins nicht feststellbar:

Verlauf der Core Web Vitals nach Ausschalten des Plugins Website Speedy.

Wir sehen keine Änderung außer anderen Einflüssen, die auf der Website ablaufen:

• Eine leichte Verschlechterung der Webgeschwindigkeit (LCP) korreliert mit einem Ausschlag im TTFB (Backend-Reaktion).
• CLS verbessert sich durch die Anpassung einer anderen Eigenschaft der Website und ist zeitlich nicht verbunden.
• Es ist wichtig zu beachten, dass CrUX-Daten von Google einen 28-Tage-kumulativen Status anzeigen, sodass Änderungen länger dauern, um sich zu manifestieren.

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

Unsere Methodik und was wir nicht behaupten#

Um fair zu sein, sollten wir im Falle unserer Recherche zu Website Speedy die Methodik klarstellen:

• Website Speedy möchte nicht, dass der Quellcode des Plugins veröffentlicht wird, daher veröffentlichen wir nur den Quellcode des Demos, das uns zur Verfügung gestellt wurde und das sich vom Quellcode des Plugins unterscheidet.
• Wir experimentierten auf der Website eines unserer Kunden.
• Wir haben hier keine quantitativen Daten aus mehreren Projekten.
• Die Deaktivierung des Plugins und unsere Untersuchung des Codes fanden im Juli 2026 statt.
• Außer der Deaktivierung des Plugins haben wir nichts Weiteres auf der Website optimiert.

Das Plugin Website Speedy hielt bei unserem Kunden das Lighthouse-Score hoch, ohne dass es den realen Nutzern eine messbar schnellere Website brachte.

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

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.

Webgeschwindigkeit? Schauen Sie sich die Core Web Vitals an. Punkt.

Als Hauptgeschäftsmetrik für die Webgeschwindigkeit sollten Sie Daten von echten Nutzern verfolgen. Core Web Vitals aus dem Chrome UX Report oder Daten aus eigener Messung (RUM). Überwachen Sie die gesamte Domain und die wichtigsten Vorlagen im Monitoring, nicht nur eine URL einmal alle paar Zeit.

Wir wissen, dass die Nachfrage nach einem Score für alles groß ist, daher verwenden wir bei PageSpeed.ONE auch unser eigenes PageSpeed.ONE Score, das auf Benutzerdaten der Core Web Vitals basiert.

In unserem einmaligen Webgeschwindigkeitstest stellen wir das Lighthouse-Score ebenfalls so weit wie möglich in den Hintergrund. Stattdessen zeigen wir Trends 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 Sie einen verdächtigen Sprung im Lighthouse-Score überprüfen können#

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 das ausgeführte JavaScript in Lighthouse mit dem normalen Laden im Browser.
• Überprüfen Sie den ersten Scroll, Klick, die Cookie-Leiste, das Öffnen eines Filters, Formular und Checkout. Lighthouse scrollt oder klickt nicht, aber der Nutzer schon.
• Prüfen Sie die Daten von Nutzern (CrUX oder RUM) vor und nach der Änderung. Ein grüneres Laborscore ohne Verbesserung der Benutzerdaten ist kein Gewinn.
• Und vor allem: Hören Sie auf, Plugins zu kaufen, die ein wundersames Beschleunigen 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 wird es auf die reale Geschwindigkeit bei den Nutzern haben, beispielsweise Core Web Vitals? Wenn er Ihnen darauf keine Antwort geben kann, kennen Sie die Antwort selbst.

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

Tags:Web PerformanceLighthouse