Falsche schnelle Websites: Wie das Lighthouse-Score gehackt wird

Die Webgeschwindigkeits-Community lebt in einem falschen Kreislauf. Menschen verwechseln nämlich das Lighthouse-Score mit der tatsächlichen Geschwindigkeit der Website. Dies wird von Plugin-Entwicklern ausgenutzt, die darauf abzielen, diese Metrik zu verbessern, ohne die tatsächliche Webgeschwindigkeit zu steigern.

Es gibt eine Vielzahl von Plugins auf dem Markt, die eine Beschleunigung der Website per Knopfdruck versprechen. Oft bleibt der Effekt jedoch nur eine Verbesserung des Lighthouse-Scores.

Was ist der Inhalt dieses Artikels in Kürze?

1. Die Gründe, warum uns das Lighthouse-Score Kopfzerbrechen bereitet, anstatt die Geschwindigkeit zu messen.
2. Das unschöne Verhalten des Plugins Website Speedy. Ein weiteres Puzzleteil in den bereits bewiesenen unlauteren Praktiken der Plugins WP-Optimize und der grenzwertigen Verhaltensweise von WP Rocket.
3. Unsere Argumente, warum wir glauben, dass die Verzögerung des Ladens von JavaScript mehr ein Trick für das Lighthouse-Score ist, als eine echte Optimierung.

Tauchen wir nun in das Problem als Ganzes ein. Wir müssen beim Hauptschuldigen beginnen, dem Lighthouse-Score und seiner Wahrnehmung durch die Laien-Community.

Geschwindigkeit der Website? Das ist das Lighthouse-Score nicht. Punkt.

Lighthouse-Score. Eine schlechte Metrik, die aber 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 kleine Rad unten. Sie wissen schon, das Lighthouse-Score.

Wir verstehen das. Es ist eine Zahl, schön bunt und lässt sich leicht an Kollegen über Slack senden… Doch das 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 uns das noch einmal wiederholen:

Lighthouse-Score ist keine Geschwindigkeit-Metrik der Website. Es ist ein technischer diagnostischer Indikator.

Die Geschwindigkeit der Website entsteht nämlich nicht in Lighthouse. Sie entsteht auf den Telefonen Ihrer Besucher, im Wi-Fi des Pubs, auf einem alten chinesischen Smartphone bei drei Balken Signal, mit zehn offenen Tabs und beim Klicken auf die Cookie-Leiste.

Das alles sieht Lighthouse nicht. Es ist nämlich kein Benutzer. Lighthouse scrollt nicht, klickt nicht, meldet sich nicht an, öffnet keine Produktfilter und geht nicht zum Checkout.

Die tatsächliche Geschwindigkeit wird durch die Metriken Core Web Vitals aus der Chrome UX Report Datenbank gemessen. (Die Unterschiede zwischen Labor 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 ein Ziel wird, hört sie auf, eine gute Metrik zu sein.“

Hier passt das perfekt. Denn genau das ist mit dem Lighthouse-Score passiert.

Menschen wollen eine einfache Zahl. Google zeigt sie (meiner Meinung nach fälschlicherweise) in PageSpeed Insights groß und farbenfroh.

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

Sobald aus einer diagnostischen Zahl ein Geschäftsargument 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.

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

Eine große Anzahl heutiger „Beschleunigungs“-Plugins hat ein Häkchen, das das Lighthouse-Score um Dutzende Punkte in fünf Sekunden Arbeit erhöhen kann. Sie verzögern das Ausführen von JavaScript bis zur ersten Benutzerinteraktion. Scrollen, Klicken, Berühren des Bildschirms.

Warum funktioniert das so zuverlässig beim Hacken des Lighthouse-Scores? Lighthouse lädt und misst die Seite. Es scrollt nicht, klickt nicht, berührt den Bildschirm nicht. Der verzögerte JavaScript wird im Test nie ausgeführt. Damit verschwinden zum Beispiel die Total Blocking Time (TBT), also die Metrik, die im Lighthouse-Score das größte Gewicht hat. Auch die Ladegeschwindigkeit (LCP) verbessert sich.

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

Illustration der Verzögerung von JavaScript. Skripte laden erst nach Benutzerinteraktion. Es ist ein Übel.

Bei PageSpeed.ONE haben wir Hunderte von Websites optimiert, aber niemals haben wir diese Technik den Kunden empfohlen. Welche Risiken gibt es bei der Verzögerung aller JavaScripts?

1. Negativer Einfluss auf Interaktionen (INP). Der Benutzer erreicht die Seite, liest die Überschrift und klickt. In diesem Moment wird all der verzögerte JavaScript ausgeführt, der sich bis dahin angesammelt hat. Der Haupt-Thread des Browsers wird blockiert und der erste Klick des Benutzers muss warten. Genau das kann die Metrik INP, die Google in die Core Web Vitals einbezieht, verschlechtern.
2. Negativer Einfluss auf Layoutverschiebungen (CLS). Skripte, die Inhalte rendern, also Karussells, Personalisierungen und andere, werden bei Verzögerung von JavaScript zu spät ausgeführt. 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 passen dann möglicherweise nicht und niemand weiß warum.
4. Entwertung des Lighthouse-Scores. Wie wir geschrieben haben, ist das Lighthouse-Score zwar keine Geschwindigkeit-Metrik der Website, aber für die Diagnose von Änderungen oder Optimierungen nützlich. Da im Lighthouse-Score kein JavaScript enthalten ist, messen Sie etwas ganz 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 ingenieurtechnische Arbeit, die Kenntnisse über die spezifische Website erfordert. Ein Häkchen, das sämtlichen JavaScript verzögert, übernimmt 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 Benutzern gefährden kann. Würden sie das angeben, würde der Kunde verstehen, dass er oft keine schnellere Website kauft, sondern nur eine bessere Zahl im Test.

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

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

Im Beispiel von WP-Optimize ist der Code zu sehen, der versucht, Lighthouse, Pingdom oder GTmetrix zu erkennen.

Der Hersteller dieses WordPress-Optimierungs-Plugins wies die Anschuldigungen öffentlich zurück. Es handele sich um eine spezifische Einstellung „Defer using JavaScript“.

Gut, aber warum gibt es diese Einstellung überhaupt? Wir sind wieder bei dem Punkt, dass solch ein Setup kein Geschwindigkeitsoptimierer macht. Allgemeine Tipps zur Geschwindigkeit auf WordPress haben wir in der Optimierung von WordPress.

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. Aktivieren Sie das Häkchen und alle Skripte warten, bis der Benutzer die Seite bewegt, klickt oder den Bildschirm berührt.

Alexander Goller schrieb bereits 2021 ausführlich in einem Artikel darüber, in dem er dieses Problem zu Recht mit dem Emissionsskandal Dieselgate vergleicht, bei dem Volkswagen-Fahrzeuge die Motoreinstellung 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 Einstellungsseite zur Verzögerung von JavaScript nur, dass es sich um eine der leistungsstärksten Optimierungen handelt.

Ein harmloses Plugin-Setting? Ich denke nicht. Auf der Funktionsseite schreibt WP Rocket nämlich nichts darüber, was das 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 nicht die Risiken.

Sowohl WP-Optimize als auch WP Rocket verkaufen diese Funktion weiterhin, ohne darauf hinzuweisen, dass sie das Lighthouse-Score künstlich erhöhen und auf die weiteren Risiken, die ich oben erwähnt 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. Ein Kunde von uns glaubte daran und nutzte dieses Plugin über Monate in der Annahme, dass er damit die Geschwindigkeit der Website verbessert.

Kollege Michal Matuška fand jedoch heraus, dass auch dieses Plugin 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 bei der Website selbst, auf der „Einfluss auf Geschäftsmessgrößen“ und „Lighthouse-Score“ in einem Atemzug genannt werden. Geschwindigkeit hat sicherlich Einfluss auf das Geschäft, aber dies lässt sich nicht mit einer synthetischen Metrik verbinden.

Bereits das Marketing dieser Erweiterungen verlässt sich nämlich auf den Benutzer, der glaubt, dass das Lighthouse-Score die Geschwindigkeit der Website ist. Und davon gibt es viele.

Die Autoren von Website Speedy geben das 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 eine Erkennung von Testwerkzeugen#

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

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

Vor der Veröffentlichung fragten wir Website Speedy nach ihrer Stellungnahme. 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 Live-Kundenwebsites überprüft hat und unsere Ergebnisse 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 verborgen.

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

Übrigens, in diesem toten Rest des Codes werden Zeichenfolgen getestet, die auffällig an die Namen der häufigsten synthetischen Messwerkzeuge erinnern, 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 passierte, als wir Website Speedy auf der Website des Kunden deaktivierten?#

Mit dem Kunden vereinbarten wir, Website Speedy vorübergehend zu deaktivieren. Wir sehen also ziemlich genau, was mit der Geschwindigkeit passiert ist, als das Plugin nicht mehr funktionierte. Fast nichts.

Das Lighthouse-Score hat sich zwar drastisch verschlechtert…

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

Nach der Deaktivierung 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.

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

Verlauf der Core Web Vitals nach Deaktivierung 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 des TTFB (Backend-Antwortzeit).
• CLS verbessert sich durch eine Anpassung einer anderen Eigenschaft der Website und ist zeitlich nicht zusammenhängend.
• Es ist gut, daran zu erinnern, dass CrUX-Daten von Google einen 28-tägigen kumulativen Zustand anzeigen, sodass Änderungen über einen längeren Zeitraum sichtbar werden.

Nach der Deaktivierung von Website Speedy normalisierte sich das Lighthouse-Score 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 Falle unserer Recherche zu Website Speedy die Methodik klären:

• Website Speedy möchte die Veröffentlichung des Quellcodes des Plugins nicht, 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 Codeuntersuchung fanden im Juli 2026 statt.
• Neben der Deaktivierung des Plugins haben wir an der Website nichts weiter optimiert.

Das Plugin Website Speedy hielt bei unserem Kunden das Lighthouse-Score hoch, ohne dass es für die realen Nutzer eine messbar schnellere Website brachte.

Ein Problem liegt also bei den Plugin-Autoren. 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.

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

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

In unserem einmaligen Webgeschwindigkeitstest rücken wir das Lighthouse-Score ebenfalls in den Hintergrund, soweit es geht. Stattdessen zeigen wir den Trend der Core Web Vitals und eine verbale Bewertung des Geschwindigkeitszustands an.

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

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

Checkliste, um verdächtiges Hacking des Lighthouse-Scores zu erkennen:

• Beginnen Sie mit der Frage, ob das Score verdächtig schnell nach der Installation eines Plugins oder einer einzigen Konfigurationsänderung gestiegen ist.
• Vergleichen Sie Netzwerk-Anfragen und ausgeführten JavaScript in Lighthouse mit dem normalen Laden im Browser.
• Überprüfen Sie den ersten Scroll, Klick, die Cookie-Leiste, das Öffnen von Filtern, Formulare und den Checkout. Lighthouse scrollt und klickt nicht, der Benutzer jedoch schon.
• Überprüfen Sie die Nutzerdaten (CrUX oder RUM) vor und nach der Änderung. Ein grüneres Lab-Score ohne Verbesserung der Nutzerdaten ist kein Gewinn.
• Und vor allem: Hören Sie auf, Plugins zu kaufen, die eine wunderbare 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 eine Sache:

Welchen Einfluss wird es auf die reale Geschwindigkeit der Nutzer haben, beispielsweise auf die 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