Ein Klick auf Analysieren, ein paar Sekunden warten, und der Lighthouse-Report erscheint: ein großer Zahlenkreis, darunter eine lange, bunte Liste aus roten und gelben Einträgen. Der erste Reflex ist verständlich, aber falsch - man arbeitet die roten Punkte von oben nach unten ab und hofft, dass der Score steigt. Genau hier verpufft viel Aufwand, denn der Score entsteht nicht aus dieser Liste. Nur fünf (Chrome for Developers) Metriken gewichten den Performance-Score, und die farbigen Opportunities darunter zählen nicht direkt hinein. Wer einen Lighthouse- oder PageSpeed-Insights-Report richtig liest, erkennt in wenigen Minuten, welche Maßnahme den größten Hebel hat - und welcher rote Eintrag getrost warten darf. Dieser Beitrag zeigt, wie die fünf Metriken den Score gewichten, warum Opportunities und Diagnostics nur indirekt wirken, wie man nach geschätztem Einsparpotenzial statt nach roter Farbe priorisiert, warum Scores zwischen zwei Läufen schwanken und wie man das Lab-Audit sauber von den Felddaten trennt. Wer aus diesem Lesen eine belastbare Prioritätenliste ableiten will, findet in einem strukturierten Lighthouse-Audit den passenden Rahmen.
Was der Report wirklich zeigt
PageSpeed Insights zeigt zwei Berichte in einem, und diese Trennung ist der Ausgangspunkt für jedes richtige Lesen. Ganz oben stehen - sofern verfügbar - die Felddaten aus dem Chrome User Experience Report (CrUX): echte Nutzererfahrungen der vergangenen 28 Tage, ausgewiesen am 75. Perzentil (web.dev). Darunter folgt das eigentliche Lab-Audit von Lighthouse: der Performance-Score, die fünf Metriken und die Liste aus Opportunities und Diagnostics. Beide Teile beantworten unterschiedliche Fragen. Die Felddaten sagen, ob echte Nutzer ein Problem erleben und ob Google es sieht; das Lab-Audit sagt, warum eine Seite langsam ist und wo man ansetzt. Dieser Beitrag behandelt das Lab-Audit - das Lesen und Umsetzen des synthetischen Berichts. Die Feldseite mit Budgets und dem 75. Perzentil vertieft unser Beitrag zu RUM gegenüber CrUX-Felddaten.
Der Performance-Score selbst ist eine Zahl von 0 bis 100 und fällt in drei Farbbänder: 0 bis 49 rot, 50 bis 89 orange und 90 bis 100 grün (Chrome for Developers). Diese Färbung verführt dazu, jeden roten Balken als gleich dringend zu behandeln. Tatsächlich ist der Score ein gewichteter Mittelwert weniger Metriken, deren Kurven aus echten Website-Daten des HTTP Archive abgeleitet sind (Chrome for Developers). Wer das versteht, liest den Report nicht als Aufgabenliste, sondern als Diagnose - und leitet daraus gezielt die wirksamsten Schritte ab, oft im Rahmen einer Performance-Analyse.
Zwei Berichte, zwei Zwecke
Die fünf Metriken, die den Score gewichten
Der gesamte Performance-Score entsteht aus genau fünf Metriken, jede mit einem festen Gewicht (Chrome for Developers). Die Liste der Opportunities und Diagnostics darunter gehört nicht dazu. Wer den Score bewegen will, muss zuerst wissen, welche Metrik wie stark zählt - denn eine Verbesserung an einer schwer gewichteten Metrik wirkt um ein Vielfaches stärker als dieselbe Mühe an einer leicht gewichteten.
| Metrik | Was sie misst | Gewicht |
|---|---|---|
| Total Blocking Time (TBT) | Summe der Hauptthread-Blockaden nach dem ersten Inhalt | 30 % |
| Largest Contentful Paint (LCP) | Zeit bis zum größten sichtbaren Element | 25 % |
| Cumulative Layout Shift (CLS) | Summe unerwarteter Layout-Verschiebungen | 25 % |
| First Contentful Paint (FCP) | Zeit bis zum ersten sichtbaren Inhalt | 10 % |
| Speed Index (SI) | wie schnell der sichtbare Bereich befüllt wird | 10 % |
Aus dieser Verteilung folgt fast alles Weitere. Total Blocking Time und Largest Contentful Paint machen zusammen fast die Hälfte des Scores aus (DebugBear), und mit Cumulative Layout Shift stehen die drei zusammen für 80 Prozent (Chrome for Developers). First Contentful Paint und Speed Index teilen sich die restlichen 20 Prozent. Jede Metrik wird zudem über eine log-normale Kurve in einen Teilscore übersetzt: Die ersten Verbesserungen bringen den größten Sprung, danach flacht der Gewinn ab (Chrome for Developers). Eine Seite von einer sehr langsamen zu einer mittleren TBT zu bringen, hebt den Score also spürbar stärker als der letzte Feinschliff einer ohnehin guten Metrik.
Praktisch heißt das: Die Total Blocking Time ist im Labor der wichtigste Hebel, und sie hängt meist an zu viel oder schlecht aufgeteiltem JavaScript, das den Hauptthread blockiert. Wie sich das mit einem Budget in Schach halten lässt, zeigt unser Beitrag zu JavaScript-Performance-Budgets. Die Total Blocking Time ist zugleich der Labor-Stellvertreter für die im Feld gemessene Interaktionslatenz, die wir im Beitrag zu Interaction to Next Paint behandeln. Cumulative Layout Shift wiederum entsteht durch springende Layouts - was dagegen hilft, beschreibt unser Beitrag zum Vermeiden von Layout-Verschiebungen.
Gewicht schlägt Farbe
Warum Opportunities und Diagnostics nur indirekt wirken
Unter dem Score listet Lighthouse zwei Blöcke: Opportunities mit einer geschätzten Zeitersparnis in Sekunden und Diagnostics mit ergänzendem Kontext. Beide sind ausgesprochen nützlich - aber nur diese fünf Metriken zählen für den Performance-Score, die Ergebnisse der Opportunities und Diagnostics fließen nicht direkt ein (DebugBear). Es gibt lediglich einen indirekten Zusammenhang: Wer eine Opportunity umsetzt, verbessert in der Regel eine der Metriken, und über diese Metrik steigt dann der Score (Chrome for Developers).
Nicht jeder rote Eintrag ist dringend
Der Wert der Opportunities liegt darin, dass sie den Weg von der Metrik zur konkreten Ursache weisen. Ein Eintrag wie ungenutztes JavaScript entfernen zielt auf die Total Blocking Time; das größte Bildelement vorladen oder korrekt dimensionieren zielt auf den Largest Contentful Paint; explizite Größenangaben für Bilder und eingebettete Inhalte zielen auf den Cumulative Layout Shift. Die Diagnostics liefern dazu den Kontext - etwa die Aufschlüsselung der Hauptthread-Arbeit oder die Anzahl der Netzwerk-Requests. Zusammen erklären sie das Warum hinter einer schwachen Metrik, das der reine Zahlenkreis nicht zeigt. Welche der fünf Metriken 2026 im Fokus stehen, ordnet unser Beitrag zu den Core Web Vitals 2026 ein.
Nach Einsparpotenzial priorisieren statt nach roter Farbe
Die eigentliche Kunst des Report-Lesens ist die Priorisierung. Statt die rote Liste von oben abzuarbeiten, verbindet man drei Informationen: Welche Metrik ist schwach und hoch gewichtet, welche Opportunity zahlt auf diese Metrik ein, und wie groß ist ihre geschätzte Ersparnis. Erst dieses Dreieck aus Gewicht, Zuordnung und Einsparpotenzial ergibt eine ehrliche Reihenfolge.
- Schwache, schwere Metrik zuerst: Beginnen Sie mit der Metrik, die am weitesten vom grünen Bereich entfernt ist und zugleich viel Gewicht trägt - meist Total Blocking Time oder Largest Contentful Paint.
- Opportunities dieser Metrik zuordnen: Filtern Sie die Liste danach, welche Empfehlung genau diese Metrik verbessert. Nur diese Einträge zahlen jetzt auf den Score ein.
- Nach geschätzter Ersparnis sortieren: Innerhalb der zugeordneten Opportunities zuerst die mit der größten Zeitersparnis, denn dort liegt der wahrscheinlich größte Metrik-Gewinn.
- Bereits grüne Metriken ausklammern: Empfehlungen, die nur eine schon gute Metrik betreffen, wandern ans Ende - unabhängig von der Farbe daneben.
- Nach jeder Aenderung neu messen: Ein Fix kann eine andere Metrik verschieben. Messen Sie erneut und ordnen Sie die Liste neu, bevor Sie den nächsten Schritt gehen.
Ein Beispiel macht den Unterschied deutlich. Angenommen, die Total Blocking Time ist rot und eine Opportunity verspricht 0,9 Sekunden durch das Entfernen ungenutzten JavaScripts - dann ist das der erste Griff, weil TBT mit 30 Prozent das höchste Gewicht trägt. Verlockt daneben eine andere Empfehlung mit 1,2 Sekunden Ersparnis, die aber nur den ohnehin guten Largest Contentful Paint betrifft, wandert sie trotz größerer Zahl nach hinten. Nicht die größte Sekundenzahl gewinnt, sondern die größte Wirkung auf den gewichteten Score. Viele dieser Ursachen sind plattformtypisch: Wie sie sich in einem Shop äußern, zeigt unser Beitrag zu Shopware-Performance und Ladezeiten; die häufigsten Bremsen in einem CMS behandelt der Beitrag zu WordPress-Performance und ihren Bremsen.
Die rote Liste ist eine Symptomanzeige, keine nach Wichtigkeit sortierte To-do-Liste. Priorität gibt das Gewicht der Metrik mal ihrem Abstand zum grünen Bereich - nicht die Farbe des Balkens.
Warum der Score schwankt
Ein häufiger Frust: Zwei Läufe kurz hintereinander, ohne jede Codeänderung, und der Score springt von 68 auf 74 und zurück. Das ist kein Fehler, sondern die Folge davon, dass eine synthetische Messung von vielen schwankenden Faktoren abhängt. Wer das kennt, verwechselt normales Rauschen nicht mit echtem Fortschritt oder Rückschritt.
Nichtdeterminismus
A/B-Tests, wechselnde Anzeigen und unterschiedlich ausgelieferte Skripte laden bei jedem Lauf anders und verändern das Ergebnis (Chrome for Developers).
Netz und Server
Paketverlust, verändertes Routing und schwankende Serverlast führen zu unterschiedlichen Antwortzeiten - vor allem bei geteiltem Hosting.
Testumgebung
Die simulierte CPU-Drosselung auf ein Gerät der Moto-G4-Klasse - rund vierfach - sowie Browser-Erweiterungen und Antiviren-Software beeinflussen den Wert (web.dev).
Die Konsequenz ist einfach: Ein einzelner Lauf ist kein verlässlicher Wert. Google empfiehlt, eine Seite mehrfach zu testen und den Median heranzuziehen, statt sich auf eine einzelne Messung zu verlassen (web.dev). So glättet man das Rauschen und erkennt, ob eine Aenderung wirklich gewirkt hat. Genau deshalb ist der Report ein Werkzeug für den wiederholten Blick, nicht für die einmalige Abnahme - schnelle Ladezeit ist ein Zustand, den man laufend absichert, wie unser Beitrag zum Zusammenhang von Ladezeit, Conversion und Umsatz zeigt.
Sauber messen
Lab von Feld trennen
Der wichtigste Denkfehler beim Report-Lesen ist, den Lab-Score als Ranking-Note zu verstehen. Google bewertet die Nutzererfahrung anhand der Felddaten aus dem Chrome User Experience Report am 75. Perzentil - nicht anhand des Lighthouse-Scores (Google Search Central). Das Lab-Audit und die Felddaten weichen aus systematischen Gründen voneinander ab, und ein perfekter Lab-Score sichert keine gute Feldbewertung zu (web.dev). Beide sind wertvoll, aber für verschiedene Zwecke: Das Labor diagnostiziert und verifiziert Aenderungen unter kontrollierten Bedingungen, das Feld zeigt, was echte Nutzer erleben.
| Aspekt | Lab-Audit (Lighthouse) | Felddaten (CrUX) |
|---|---|---|
| Umgebung | eine simulierte Messung, festes Gerät und Netz | echte Chrome-Nutzer, alle Geräte und Netze |
| Was es beantwortet | warum eine Seite langsam ist | ob echte Nutzer ein Problem erleben |
| Ranking-Einfluss | kein direkter | Bewertung am 75. Perzentil |
| Beste Nutzung | Diagnose und Regressionscheck | Maßstab für die Realität |
In der Praxis arbeiten beide zusammen: Man liest im Feldbericht, ob überhaupt ein Problem existiert, und nutzt dann das Lab-Audit, um die Ursache zu finden und einen Fix zu verifizieren. Wer nur den Lab-Score jagt, optimiert womöglich an einem Wert vorbei, der im Feld gar nicht klemmt - oder übersieht ein Feldproblem, das im einzelnen Laborlauf nicht auftaucht. Wie man Felddaten, Budgets und das 75. Perzentil zusammenführt, vertieft unser Beitrag zu RUM gegenüber CrUX-Felddaten.
Vom Report zur Prioritätenliste
In unseren Projekten behandeln wir den Report konsequent als Diagnose, nicht als Abhakliste. Zuerst trennen wir Lab- und Felddaten und klären, ob überhaupt ein Feldproblem vorliegt. Dann lesen wir das Lab-Audit entlang der fünf gewichteten Metriken, ordnen die Opportunities den schwachen, schwer gewichteten Metriken zu und sortieren sie nach geschätztem Einsparpotenzial. Anschließend setzen wir die wirksamsten Schritte um - meist an Total Blocking Time und Largest Contentful Paint - messen den Median mehrerer Läufe und prüfen die Wirkung anschließend in den Felddaten. Dieses Vorgehen ist der Kern einer strukturierten Performance-Analyse und fließt in die laufende Frontend-Optimierung ein.
Lesen
Lab von Feld trennen, den Score als gewichteten Mittelwert der fünf Metriken verstehen und die Opportunities als Ursachen-Hinweise, nicht als Rangliste lesen.
Priorisieren
Nach Gewicht mal Abstand zum grünen Bereich ordnen, Opportunities der jeweiligen Metrik zuordnen und innerhalb dieser nach geschätzter Ersparnis reihen.
Umsetzen und belegen
Die wirksamsten Schritte umsetzen, den Median mehrerer Läufe messen und die Verbesserung im Feld nachweisen - statt einem einzelnen Lauf zu vertrauen.
So wird aus einem bunten Bericht eine klare Reihenfolge, die den Aufwand dorthin lenkt, wo er am meisten bewegt. Wer seinen Report nicht nur ansehen, sondern in eine belastbare Prioritätenliste übersetzen will, erhält mit einem professionellen Lighthouse-Audit einen strukturierten Performance-Report - und mit ihm den Rahmen, in dem sich die einzelnen Schritte zu messbaren Leistungen rund um Web-Performance fügen.
Quellen und Studien