Lighthouse berechnet den Performance-Score aus gewichteten Metrikbewertungen, nicht aus der Anzahl der Warnungen. Jeder Rohwert wird zunächst über eine Bewertungskurve umgerechnet. Eingesparte Millisekunden und gewonnene Punkte stehen deshalb nicht in einem linearen Verhältnis. Vergleichen Sie mehrere Durchläufe mit derselben Lighthouse-Version, demselben Geräteprofil, derselben Drosselung und demselben Seitenzustand und betrachten Sie zusätzlich Daten tatsächlicher Nutzer.
Prüfen Sie die Version vor der Gewichtung
Als die Lighthouse-Veröffentlichungen am 17. Oktober 2026 geprüft wurden, war v13.5.0 die neueste aufgeführte Softwareversion. Daraus folgt nicht, welche Version eine bestimmte PageSpeed-Insights-Anfrage oder Ihre Chrome-Installation verwendet. Verteilung und lokale Installation können voneinander abweichen. Für einen Vergleich zählt die im Bericht angegebene Version.
Auch die Dokumentation erfordert eine Unterscheidung. Chromes allgemeine Bewertungsseite bezeichnet ihre bekannte Tabelle weiterhin als „Lighthouse 10“. Die für diesen Artikel geprüfte Konfiguration im Hauptzweig enthält dieselben fünf Gewichte ungleich null. Die Konfiguration unter dem Tag v13.5.0 konnte nicht verifiziert werden. Die folgende Tabelle beschreibt daher den geprüften Hauptzweig und das dokumentierte Lighthouse-10-Modell, keine separat bestätigte v13.5.0-Konfiguration. Prüfen Sie bei versionsgebundenen Audits deren JSON wie unten gezeigt.
Diese Gewichte sind in den beiden genannten Quellen nachgewiesen.
| Metrik | Gewicht | Aussage |
|---|---|---|
| First Contentful Paint (FCP) | 10% | Zeitpunkt des ersten berücksichtigten Inhalts |
| Speed Index (SI) | 10% | Geschwindigkeit, mit der sich der sichtbare Inhalt beim Laden aufbaut |
| Largest Contentful Paint (LCP) | 25% | Zeitpunkt des größten berücksichtigten sichtbaren Inhalts |
| Total Blocking Time (TBT) | 30% | Blockierende Anteile langer Hauptthread-Aufgaben im Messfenster |
| Cumulative Layout Shift (CLS) | 25% | Unerwartete Bewegungen während des geprüften Ladevorgangs |
In der geprüften Konfiguration steht INP mit Gewicht null. Ein normaler Navigationsscore ist somit kein INP-Score. TBT kann untersuchungswürdige Hauptthread-Arbeit aufzeigen. Ersetzt man aber INP tatsächlicher Nutzer durch TBT, beantwortet man eine andere Frage.
Eine andere Berichtsstruktur bedeutet nicht automatisch eine andere Bewertung. Lighthouse 13 führte ältere Performance-Audits in Insights zusammen. Die Veröffentlichung erklärte ausdrücklich, dass sich der Performance-Score dadurch nicht änderte. Ein verschwundener Auditname beweist nicht, dass das zugrunde liegende Problem bedeutungslos geworden ist.
Rechnen Sie Messwerte vor dem Mitteln um
LCP ist eine Zeitdauer, CLS dagegen einheitenlos. Beide direkt zu addieren wäre nicht sinnvoll. Lighthouse wandelt jeden Messwert zunächst in seine eigene Bewertung um und kombiniert anschließend die Bewertungen mit ihren Gewichten.
Google beschreibt logarithmisch normalverteilte Bewertungskurven, die durch HTTP-Archive-Daten informiert sind. Gleich große Messwertverbesserungen bringen daher nicht immer gleich viele Punkte. In einem steilen Kurvenabschnitt kann eine Änderung deutlich sichtbar werden, nahe dem Maximum verändert sie die angezeigte Ganzzahl möglicherweise kaum. Auch Mobil- und Desktopbewertungen sind nicht austauschbar: Einstellungen und Bewertungserwartungen unterscheiden sich.
Als reines Rechenbeispiel bleiben alle Metrikbewertungen unverändert, während die normalisierte TBT-Bewertung auf einer Skala von 0 bis 100 um 10 Punkte steigt. Bei 30% Gewicht verbessert sich ihr Beitrag zum Gesamtergebnis vor der Rundung um 3 Punkte. Das ist eine hypothetische Berechnung, kein Benchmark und keine Zusage für eine bestimmte Codeänderung.
Unterscheiden Sie Messwert und Metrikbewertung. 100 Millisekunden weniger Arbeit bedeuten weder 100 Punkte mehr noch einen anderen festen Punktgewinn. Ausgangswert, Kurve, Messfenster und übrige Metriken beeinflussen das Ergebnis. Eine Optimierung kann zudem mehrere Metriken gleichzeitig verändern und einfache Prognosen zusätzlich erschweren.
Die offizielle Erklärung der Bewertung erläutert das Modell. Wählen Sie die konkrete Entwicklungsaufgabe anhand Ihres Berichts. Ein kleiner Punktgewinn kann eine erhebliche Verbesserung eines langsamen Seitenelements begleiten, insbesondere wenn eine andere Metrik den Gesamtwert weiterhin begrenzt.
Warnungen erklären Ursachen statt direkter Punktabzüge
Ein renderblockierendes Stylesheet verursacht keinen universellen Abzug einer festen Punktzahl. Entscheidend ist, ob es Inhalte verzögert, die in die gemessenen Metriken eingehen. Ebenso weist eine Warnung über ungenutztes JavaScript auf möglicherweise entbehrliche Arbeit hin; die Warnung ist keine zusätzliche gewichtete Metrik.
Das verhindert zwei typische Fehler. Alle Warnungen abzuarbeiten verbessert nicht automatisch die Nutzungserfahrung. Außerdem lassen sich geschätzte Einsparungen verschiedener Insights nicht zuverlässig addieren. Sie können sich überlappen, dieselbe Anfragekette betreffen oder bei gemeinsamer Umsetzung die Browserplanung verändern.
Untersuchen Sie Wasserfall und Hauptthread-Zeitleiste vor der Änderung. Ein spät entdecktes Hauptbild ist ein anderes Problem als ein früh entdecktes, langsam übertragenes Bild. Wenn JavaScript den Hauptthread belegt, beginnen Sie mit der Reduzierung der JavaScript-Ausführungszeit, statt ein bereits kleines Bild erneut zu komprimieren.
Bewahren Sie einzelne Metriken auch dann auf, wenn intern eine einzige Kennzahl gewünscht wird. Ein höherer Gesamtwert kann eine Verschlechterung verdecken. Beispielsweise kann besseres CLS langsamere Inhaltsdarstellung im gewichteten Ergebnis ausgleichen. Der Gesamtwert sagt allein nicht, ob dieser Kompromiss für Ihre Seite sinnvoll ist.
Kontrollieren Sie die Ursachen schwankender Ergebnisse
Lighthouse misst ein laufendes System. Hintergrundlast der CPU, Erweiterungen, wechselnde Anzeigen, Experimente, Cachezustand, Netzrouten und Backendlast verändern den Ablauf. Ein Browser mit injiziertem Erweiterungscode beobachtet nicht dieselbe Arbeitslast wie ein sauberes Profil.
Die Drosselungsmethode schafft eine weitere Vergleichsgrenze. Simulierte Drosselung schätzt Leistung aus einer aufgezeichneten Spur; angewendete Drosselung begrenzt den Lauf selbst. Ein Ergebnis der einen Methode ist keine exakte Wiederholung eines Ergebnisses der anderen. Halten Sie die Methode konstant und dokumentieren Sie sie.
Dieselbe URL kann unterschiedliche Erfahrungen ausliefern. Ein Einwilligungsbanner, ein angemeldetes Konto, geografischer Inhalt oder ein Experiment verändert DOM, Anfragen und Skripte. Dokumentieren Sie den Zustand, statt die URL für eine vollständige Versuchsbeschreibung zu halten. Prüfen Sie wichtige Produktionszustände getrennt.
Ein erster Besuch ohne Cache und ein Folgebesuch verdienen getrennte Betrachtung. Gecachte Schriften oder Skripte verändern den kritischen Pfad, gespeichertes HTML die Serverzeit. Halten Sie die beabsichtigte Cachepolitik bei Ausgangs- und Vergleichsversion gleich. Schreiben Sie einen Unterschied zwischen kaltem Ausgangslauf und warmem Vergleichslauf nicht vollständig Ihrer Codeänderung zu.
Nutzen Sie für lokale Vergleiche einen stabilen, möglichst unbelasteten Rechner. Schließen Sie schwere Anwendungen, führen Sie Audits nicht parallel aus und verwenden Sie ein sauberes Browserprofil. Halten Sie die Energieeinstellungen konstant. Das reduziert vermeidbares Rauschen, macht einen Laptop aber nicht zu einer repräsentativen Stichprobe aller Besucher.
Erstellen Sie einen reproduzierbaren CLI-Vergleich
Mit der CLI lassen sich Befehl, Paketversion und Ausgabe gemeinsam speichern. Voraussetzung sind eine kompatible Node.js-Installation und Chrome oder Chromium. Prüfen Sie vor der Installation die Laufzeitanforderungen des gewählten Pakets. Die folgenden Beispiele wählen die bei der Recherche beobachtete Version. Sie wurden für diesen Artikel nicht gegen example.com ausgeführt.
Speichern Sie fünf getrennte JSON-Berichte mit einer festen Version und dem standardmäßigen Mobilprofil.
mkdir -p lighthouse-reports
for run in 1 2 3 4 5; do
npx --yes [email protected] https://example.com/ --only-categories=performance --chrome-flags="--headless" --output=json --output-path="lighthouse-reports/mobile-${run}.json"
doneFünf Läufe sind ein praktischer Einstieg, keine statistische Garantie und keine offizielle Bestehensanforderung. Nutzen Sie dasselbe Verfahren für Ausgangs- und Änderungsversion. Bei großer Streuung suchen Sie zuerst die Ursache, bevor Sie einen kleinen Unterschied als Fortschritt bewerten.
Lesen Sie Version, Gewichte ungleich null und Score direkt aus einem gespeicherten Bericht.
// inspect-lighthouse.mjs
import { readFileSync } from 'node:fs';
const file = process.argv[2];
if (!file) throw new Error('Pass a Lighthouse JSON report path.');
const report = JSON.parse(readFileSync(file, 'utf8'));
const performance = report.categories.performance;
console.log('Lighthouse version:', report.lighthouseVersion);
console.log('Performance score:', performance.score);
console.table(performance.auditRefs.filter(({ weight }) => weight > 0));Führen Sie das Skript mit dem ersten Bericht aus.
node inspect-lighthouse.mjs lighthouse-reports/mobile-1.jsonDer JSON-Score ist normalisiert: 0.9 entspricht vor der Darstellungsformatierung 90. Speichern Sie vollständige Berichte statt nur Gesamtwerte. Einstellungen und Metriken helfen, Unterschiede später zu erklären. Für Desktopmessungen erstellen Sie eine eigene Serie mit --preset=desktop; vermischen Sie diese nicht mit den Mobilwerten.
Verwenden Sie Mediane und zeigen Sie die Streuung
Sortieren Sie die wiederholten Scores und berichten Sie den mittleren Wert als einfachen Median. Bewahren Sie zusätzlich Minimum, Maximum und einzelne Metrikwerte auf. Der Median reagiert weniger auf einen außergewöhnlich schnellen oder langsamen Lauf, repariert aber keinen unzureichend kontrollierten Versuch.
Erzeugen Sie keinen künstlichen „Bestbericht“ aus dem schnellsten LCP eines Laufs, dem niedrigsten TBT eines zweiten und dem niedrigsten CLS eines dritten. Diese Kombination ist nie aufgetreten. Ein repräsentativer Bericht und die vollständige Serie erhalten die Zusammenhänge zwischen den Messwerten.
Eine brauchbare Vergleichsnotiz nennt URL und Revision, Seitenzustand, Browser- und Lighthouse-Version, Geräteprofil, Drosselungsmethode, Anzahl der Läufe, Median und relevante Streuung. Ergänzen Sie die untersuchte Änderung und bekannte Umgebungsunterschiede. So entsteht reproduzierbare Evidenz statt einer isolierten Zahl.
PageSpeed Insights, DevTools und CLI können unterschiedliche Versionen und Umgebungen verwenden. Der PageSpeed-Insights-Leitfaden erklärt dessen Bericht. Bei abweichenden Ergebnissen vergleichen Sie zuerst Einstellungen und Zustände. Die niedrigere Punktzahl beweist nicht, dass das betreffende Werkzeug falsch misst.
Leiten Sie die nächste sinnvolle Messung ab
100 Punkte sind ein gerundetes Laborergebnis unter bestimmten Bedingungen, kein Zertifikat für schnelle Besuche sämtlicher Nutzer. Der Lauf prüft nicht jede Route, Interaktion, Sprache, Sitzungsdauer oder jedes Gerät. Spätere Layoutverschiebungen und langsame Interaktionen können im Navigationsaudit fehlen.
Betrachten Sie Feld- und Labordaten gemeinsam. Kontrollierte Tests erklären Änderungen kurzfristig; Nutzermessungen zeigen anschließend, ob die gewünschte Zielgruppe profitiert. Unterschiede können eine fehlende Testbedingung aufdecken, ohne einen der Datensätze zu entwerten.
Wählen Sie für die nächste Iteration eine langsame Metrik, ermitteln Sie deren Anfrage- oder Hauptthread-Ursache und setzen Sie eine überprüfbare Änderung um. Speichern Sie eine wiederholbare Ausgangsmessung mit dem PageSpeed-Analyzer, sofern eingerichtet, oder mit der CLI. Folgen Sie anschließend dem passenden Leitfaden zur Ladezeitoptimierung. Das sinnvolle Ziel ist eine belegte Verbesserung, die wiederholten Tests standhält und Nutzer erreicht.
