Lighthouse Performance Score

Der Lighthouse Performance Score ist die Zahl zwischen 0 und 100 am Kopf jedes Pagespeed-Insights-Reports und die Zahl, die die meisten nennen, wenn sie von „Pagespeed“ sprechen. Er ist ein Laborwert: Lighthouse lädt die Seite einmal in einer simulierten Umgebung, misst eine Handvoll Metriken und verrechnet sie mit festen Gewichten. Das macht ihn nützlich für die Diagnose und für den Vergleich zweier Versionen derselben Seite, und ungeeignet als Ziel an sich. Dieser Ratgeber erklärt, wie der Score berechnet wird, warum er zwischen zwei Läufen schwankt, wie er sich zu den Core Web Vitals verhält, die Google tatsächlich nutzt, und wie Sie ihn verbessern, ohne das Falsche zu optimieren.

Aus den Messungen von PerfDelta: Der mittlere mobile Lighthouse-Score der 5.472 gemessenen Startseiten liegt bei 43. Nur 2 % erreichen 90 oder mehr, 62 % bleiben unter 50. Mehr dazu im Datenblock unten.

So wird der Score berechnet

Lighthouse misst im Laborlauf fünf Metriken und übersetzt jede über eine logarithmische Normalverteilung, kalibriert an realen Daten des HTTP Archive, in einen Teilwert von 0 bis 100. Die Teilwerte werden dann gewichtet:

Metrik	Gewicht	Was sie erfasst
Total Blocking Time	30 %	wie lange lange Tasks den Hauptthread beim Laden blockieren
Largest Contentful Paint	25 %	wann der Hauptinhalt sichtbar ist
Cumulative Layout Shift	25 %	wie stark sich das Layout beim Laden verschiebt
First Contentful Paint	10 %	wann der erste Inhalt sichtbar ist
Speed Index	10 %	wie schnell sich der sichtbare Bereich füllt

Die Gewichte gelten ab Lighthouse 10; frühere Versionen enthielten noch Time to Interactive und gewichteten anders. Das ist ein Grund, warum Scores aus alten Reports nicht vergleichbar sind. Ein Score von 90 bis 100 erscheint grün (gut), 50 bis 89 orange (verbesserungswürdig), 0 bis 49 rot (schlecht). Wegen der logarithmischen Kurven sind die letzten Punkte in Richtung 100 deutlich schwerer zu verdienen als die ersten Punkte weg von 0.

Die unter dem Score gelisteten Befunde, etwa renderblockierende Ressourcen oder nicht verwendetes JavaScript, fließen nicht direkt in den Score ein. Sie sind Diagnosen, die erklären, warum die Metriken so ausgefallen sind.

Warum der Score zwischen Läufen schwankt

Zweimal Lighthouse auf derselben Seite ergibt selten dieselbe Zahl. Die Testmaschine und ihre aktuelle Auslastung, der Netzwerkpfad zum Server, A/B-Tests und Werbung auf der Seite und der Cache-Zustand der Seite variieren. Ein Unterschied von wenigen Punkten zwischen zwei Läufen bedeutet nichts. Lighthouse selbst dokumentiert diese Schwankung und empfiehlt für Vergleiche mehrere Läufe oder eine kontrollierte Umgebung. Das Monitoring von PerfDelta begegnet dem mit Messungen in festem Takt und zeigt den Trend statt einzelner Werte.

Lab-Score gegen Core-Web-Vitals-Felddaten

Der Score ist nicht das, was Google für das Ranking nutzt. Googles Signale zur Seitenerfahrung stützen sich auf die Core Web Vitals aus dem Chrome UX Report: echte Besucher, echte Geräte, das 75. Perzentil über 28 Tage. Drei Unterschiede sind entscheidend:

• Gerät und Netz. Der mobile Laborlauf simuliert ein Mittelklasse-Smartphone mit langsamer 4G-Verbindung. Nutzen Ihre Besucher überwiegend aktuelle Smartphones in schnellen Netzen, sehen die Felddaten deutlich besser aus als der Lab-Score.
• INP hat kein Labor-Gegenstück. Der Score nimmt die Total Blocking Time als Näherung für die Reaktionsfähigkeit; das Feld misst den INP an echten Interaktionen. Eine Seite kann beim Laden den Hauptthread blockieren und später trotzdem gut reagieren, oder umgekehrt.
• Ein Ladevorgang gegen tausende. Das Labor testet einen kalten Aufruf einer URL. Das Feld fasst jeden Seitenaufruf zusammen, auch Wiederbesuche mit gefülltem Cache.

Die praktische Folge: Eine Seite kann einen Lab-Score um 30 haben und die Core Web Vitals bei echten Nutzern bestehen, und eine Seite mit einem Score über 90 kann im Feld am INP scheitern. Beides kommt in unseren Messungen regelmäßig vor; der Datenblock unten zeigt, wie oft. Wo beide auseinanderfallen, entscheiden die Felddaten darüber, was Google sieht, und der Lab-Score sagt, wo Sie suchen müssen.

So verbessern Sie den Performance Score

Wegen der Gewichte ist der schnellste Weg zu einem höheren Score, mit den schwersten Posten zu beginnen:

1. Total Blocking Time (30 %). JavaScript reduzieren und zurückstellen, lange Tasks aufteilen, Drittanbieter-Skripte begrenzen. Siehe JavaScript-Ausführungszeit reduzieren und Drittanbieter-Code.
2. Largest Contentful Paint (25 %). Das LCP-Bild früh auffindbar und hoch priorisiert machen, renderblockierende Ressourcen entfernen und die TTFB niedrig halten.
3. Cumulative Layout Shift (25 %). Platz für Bilder, Werbung und Einbettungen reservieren und Schriften mit größenangepasster Ersatzschrift laden (siehe font-display).
4. FCP und Speed Index (je 10 %). Beide folgen aus den Schritten oben; kritisches CSS inline und ein kleines HTML-Dokument helfen zusätzlich.

Verzichten Sie auf Abkürzungen, die den Score heben, ohne Besuchern zu helfen: sämtliches JavaScript erst nach Ende des Lighthouse-Laufs laden, dem Testagenten eine andere Seite ausliefern oder Inhalte bis zum Ende der Messung verstecken. Das ist leicht zu erkennen, bringt für die Felddaten nichts und macht den Diagnosewert des Scores zunichte.

Was ein guter Score ist

Werten Sie 90 und mehr als Zeichen, dass die Seite keine großen, im Labor sichtbaren Probleme hat, und 50 als die Linie, unter der ein Mittelklasse-Smartphone mit langsamer Verbindung eine schlechte Erfahrung macht. Dazwischen hilft die Aufschlüsselung nach Metriken mehr als die einzelne Zahl. Das Ziel für das Geschäft sind bestandene Core Web Vitals im Feld; der Score ist das Werkzeug auf dem Weg dorthin.

Häufige Fragen

Beeinflusst der Lighthouse Score das Google-Ranking?

Nicht direkt. Google nutzt die Core-Web-Vitals-Felddaten aus dem Chrome UX Report. Der Score ist ein Laborwerkzeug, mit dem Sie die Ursachen schlechter Felddaten finden und beheben.

Warum ist mein mobiler Score so viel niedriger als der Desktop-Score?

Der mobile Lauf drosselt CPU und Netz, um ein Mittelklasse-Smartphone mit langsamem 4G zu simulieren. JavaScript braucht dort ein Mehrfaches der Zeit, große Dateien kommen später an.

Warum ändert sich mein Score bei jedem Testlauf?

Auslastung der Testmaschine, Netzbedingungen, Werbung und A/B-Tests schwanken zwischen Läufen. Unterschiede von wenigen Punkten sind Rauschen; vergleichen Sie Trends über mehrere Läufe.

Kann eine Seite mit schlechtem Score die Core Web Vitals bestehen?

Ja, und das kommt oft vor, weil echte Besucher meist schnellere Geräte und Netze haben als die Laborsimulation. Auch das Gegenteil kommt vor, besonders beim INP, den das Labor nicht messen kann.