Wie man einen Lighthouse-Bericht liest, ohne in Panik zu geraten

Die erste Regel: Ihr Score ist nicht Ihre Website

Wenn Sie zum ersten Mal einen Lighthouse-Bericht öffnen, sehen Sie eine Wand aus Zahlen, farbcodierten Kästen und Warnungen zu Dingen, von denen Sie noch nie gehört haben. Die natürliche Reaktion ist Panik. Der Score ist rot. Siebzehn Audits sind fehlgeschlagen. Die Website muss kaputt sein, oder?

Wahrscheinlich nicht. Lighthouse ist ein Diagnosewerkzeug, kein Zeugnis. Der Score ist ein synthetischer Benchmark unter Laborbedingungen – oft mit gedrosselter Verbindung und der Simulation eines Mittelklasse-Smartphones aus dem Jahr 2017. Er sagt Ihnen, wie Ihre Website in genau diesem Szenario abschneidet, nicht wie echte Nutzer sie in der Praxis erleben.

Das ist wichtig, weil die meisten Teams sich auf den Score fixieren und den Kontext übersehen. Ein Score von 65 kann für eine komplexe Web-App mit Echtzeitdaten in Ordnung sein. Ein Score von 95 kann trotzdem eine schlechte Erfahrung liefern, wenn die falschen Dinge optimiert wurden. Der Score ist ein Ausgangspunkt für Untersuchungen, keine Erfolgskennzahl.

Was Sie zuerst lesen sollten: Core Web Vitals

Überspringen Sie den gesamten Performance-Score. Scrollen Sie nach unten zum Abschnitt Metrics und betrachten Sie drei Werte: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) und Interaction to Next Paint (INP). Das sind die Core Web Vitals, und sie sind die einzigen Performance-Metriken, die Google als Ranking-Signal verwendet.

• LCP misst, wie lange es dauert, bis das größte sichtbare Element gerendert ist. Ziel: unter 2,5 Sekunden. Wenn Sie über 4 Sekunden liegen, warten Nutzer zu lange, bis sie relevante Inhalte sehen.
• CLS misst die visuelle Stabilität – also wie stark die Seite beim Laden springt. Ziel: unter 0,1. Wenn Sie über 0,25 liegen, klicken Nutzer versehentlich auf das Falsche, weil sich Schaltflächen verschoben haben.
• INP misst die Reaktionsfähigkeit – also wie schnell die Seite auf Klicks, Taps und Tastatureingaben reagiert. Ziel: unter 200 ms. Wenn Sie über 500 ms liegen, fühlt sich die Website träge an.

Diese drei Metriken korrelieren mit tatsächlicher Nutzerfrustration. Beheben Sie diese Punkte, bevor Sie sich um irgendetwas anderes kümmern.

Opportunities vs. Diagnostics: den Unterschied kennen

Lighthouse teilt seine Ergebnisse in zwei Kategorien ein: Opportunities und Diagnostics. Opportunities werden nach geschätzter Zeitersparnis sortiert. Diagnostics liefern zusätzlichen Kontext – Dinge, die Probleme sein können, aber nicht müssen.

Beginnen Sie mit Opportunities. Wenn Lighthouse sagt, dass "Eliminate render-blocking resources" 1,2 Sekunden sparen könnte, ist das ein konkreter Gewinn. Wenn dort steht, dass "Reduce unused JavaScript" 0,1 Sekunden sparen könnte, ist das Refactoring wahrscheinlich nicht den Aufwand wert.

Diagnostics sind schwieriger. "Avoid an excessive DOM size" klingt schlecht, aber wenn Ihr CLS in Ordnung und Ihr INP schnell ist, schadet ein großes DOM möglicherweise niemandem. Diagnostics sind Hinweise, keine Vorgaben. Untersuchen Sie diejenigen, die zu Ihren tatsächlichen Metriken passen.

Die Audits, die Sie meist ignorieren können

Einige Lighthouse-Warnungen sind Überbleibsel oder übermäßig streng. Das sind die, die am häufigsten unnötige Panik auslösen:

• "Does not use passive listeners to improve scrolling performance" — Das ist eine Mikrooptimierung, die selten einen spürbaren Unterschied macht. Wenn Sie keine Hinweise auf ruckeliges Scrollen haben, überspringen Sie sie.
• "Image elements do not have explicit width and height" — Das ist für CLS relevant, aber nur, wenn Bilder Layout-Verschiebungen verursachen. Wenn Ihr CLS bereits gut ist, sollten Sie nicht nur wegen dieses Audits refactoren.
• "Serve images in next-gen formats" — Ja, WebP und AVIF sind kleiner. Aber wenn Ihre Bilder bereits optimiert sind und Ihr LCP schnell ist, ist das ein Nice-to-have, keine Krise.
• "Avoid enormous network payloads" — Lighthouse markiert alles über 1,6 MB. Aber eine 2-MB-Seite, die schnell lädt, ist besser als eine 500-KB-Seite, die das Rendering blockiert. Konzentrieren Sie sich darauf, wie die Bytes ausgeliefert werden, nicht nur auf die Gesamtsumme.

Was tun, wenn alles rot ist

Wenn Ihr Lighthouse-Score unter 50 liegt und die meisten Audits fehlschlagen, haben Sie es wahrscheinlich mit einer von drei Hauptursachen zu tun:

1. Nicht optimierte Schriftarten. Web Fonts sind auf den meisten Websites immer noch der einfachste Performance-Gewinn. Prüfen Sie, ob Sie sechs Schriftschnitte laden, obwohl Sie nur zwei verwenden, oder ob Sie WOFF-Dateien statt WOFF2 ausliefern.
2. Render-blocking CSS und JavaScript. Wenn Ihr First Contentful Paint (FCP) über 3 Sekunden liegt, hindert etwas den Browser daran, zu zeichnen. Suchen Sie nach großen CSS-Dateien oder synchronen Skripten im <head>.
3. Zu große Bilder. Wenn Ihr LCP-Element ein Bild ist und es 4 MB groß ist, ist das Ihr Problem. Komprimieren Sie es, laden Sie Bilder unterhalb des sichtbaren Bereichs per Lazy Loading und verwenden Sie responsive Bildsyntax.

Beheben Sie eines dieser Probleme und führen Sie Lighthouse erneut aus. Oft sehen Sie einen Sprung um 20 bis 30 Punkte. Danach nehmen Sie sich das nächste vor.

Labordaten vs. Felddaten: der Realitätscheck

Lighthouse läuft im Labor. Es simuliert eine langsame Verbindung und ein langsames Gerät, kann aber kein echtes Nutzerverhalten simulieren – wie Menschen scrollen, worauf sie klicken oder ob sie in einem instabilen WLAN sind.

Für einen Realitätscheck vergleichen Sie Ihre Lighthouse-Ergebnisse mit Felddaten aus dem Chrome User Experience Report (CrUX). CrUX zeigt, wie echte Chrome-Nutzer Ihre Website in den letzten 28 Tagen erlebt haben. Wenn Lighthouse sagt, Ihr LCP liege bei 4 Sekunden, CrUX aber 2 Sekunden zeigt, vertrauen Sie CrUX. Wenn beide schlecht sind, haben Sie ein echtes Problem.

Sie finden CrUX-Daten in PageSpeed Insights (der Webversion von Lighthouse) oder in Google Search Console unter "Core Web Vitals." Wenn es eine Abweichung gibt, untersuchen Sie den Grund. Vielleicht nutzen Ihre echten Nutzer schnellere Netzwerke. Vielleicht testet Lighthouse einen nicht optimierten Dev-Build.

Wann Sie Lighthouse erneut ausführen sollten

Lighthouse ist schwankungsanfällig. Führen Sie es dreimal hintereinander aus, und Sie erhalten drei verschiedene Scores – sogar auf derselben Seite. Das liegt daran, dass Performance variabel ist: Hintergrundprozesse, Netzwerk-Jitter und Browser-Heuristiken beeinflussen alle das Ergebnis.

Um eine stabile Ausgangsbasis zu erhalten, führen Sie Lighthouse im Inkognitomodus mit deaktivierten Erweiterungen aus oder verwenden Sie die CLI mit dem Flag --preset=desktop für konsistentere Ergebnisse. Führen Sie es dreimal aus und mitteln Sie die Scores. Wenn Sie starke Ausschläge sehen (mehr als 10 Punkte), stimmt etwas anderes nicht – vielleicht ist der Server langsam, oder die Seite lädt jedes Mal unterschiedliche Ressourcen.

Führen Sie Lighthouse nach jeder größeren Änderung erneut aus. Neue Font-Strategie ausgerollt? LCP prüfen. Bilder per Lazy Loading geladen? CLS prüfen. Ein Third-Party-Skript hinzugefügt? INP prüfen. Performance ist keine einmalige Korrektur; sie ist ein Budget, das Sie verteidigen.

Die Tools, mit denen Sie Lighthouse-Ergebnisse umsetzen

Lighthouse sagt Ihnen, was langsam ist. Es sagt Ihnen nicht immer, wie Sie es beheben. Dafür brauchen Sie zusätzliche Tools:

• WebPageTest bietet Ihnen eine Filmstreifenansicht davon, wie die Seite Bild für Bild lädt. Unverzichtbar für die Diagnose von LCP- und CLS-Problemen.
• Chrome DevTools Performance panel zeigt Ihnen genau, welches JavaScript den Main Thread blockiert. Nutzen Sie es, um die Ursache eines schlechten INP-Scores zu finden.
• Tools zur Bildkomprimierung ermöglichen es Ihnen, Bilder direkt im Browser zu optimieren – schneller und privater als der Upload zu einem Drittanbieterdienst. Clientseitige Bildverarbeitung ist ein Gewinn für die Privatsphäre, weil Ihre Bilder Ihren Rechner nie verlassen.

Lighthouse ist der Ausgangspunkt. Diese Tools helfen Ihnen, die Arbeit abzuschließen.

Wichtigste Erkenntnisse

• Ihr Lighthouse-Score ist ein Labor-Benchmark, kein Maß für die reale Nutzererfahrung. Vergleichen Sie ihn mit Felddaten aus CrUX, bevor Sie in Panik geraten.
• Konzentrieren Sie sich zuerst auf Core Web Vitals (LCP, CLS, INP). Das sind die Metriken, die mit Nutzerfrustration und SEO-Auswirkungen korrelieren.
• Priorisieren Sie Opportunities nach geschätzter Zeitersparnis. Ignorieren Sie Diagnostics, die nicht zu Ihren tatsächlichen Performance-Problemen passen.
• Einige Audits – etwa passive Listener oder Bildformate der nächsten Generation – sind Mikrooptimierungen. Beheben Sie zuerst die großen Dinge.
• Führen Sie Lighthouse dreimal aus und mitteln Sie die Ergebnisse. Performance ist variabel, und ein einzelner Lauf kann irreführend sein.

FAQ

Q: Warum ändert sich mein Lighthouse-Score jedes Mal, wenn ich ihn ausführe?
A: Lighthouse misst Performance unter variablen Bedingungen – Netzwerkgeschwindigkeit, CPU-Last und Browser-Heuristiken beeinflussen alle das Ergebnis. Führen Sie es dreimal im Inkognitomodus aus und mitteln Sie die Scores, um eine stabilere Ausgangsbasis zu erhalten.

Q: Sollte ich zuerst für Mobile oder Desktop optimieren?
A: Mobile. Lighthouse verwendet standardmäßig eine mobile Simulation, weil der meiste Web-Traffic mobil ist und mobile Geräte langsamer sind. Wenn Ihr Mobile-Score gut ist, ist Ihr Desktop-Score in der Regel ebenfalls in Ordnung.

Q: Mein Lighthouse-Score liegt bei 95, aber meine Website fühlt sich trotzdem langsam an. Was stimmt nicht?
A: Lighthouse misst das Laden der Seite, nicht die Interaktivität nach dem Laden. Prüfen Sie Ihren INP-Score und verwenden Sie das Chrome DevTools Performance panel, um zu profilieren, was passiert, wenn Nutzer klicken oder scrollen. Möglicherweise haben Sie ein JavaScript-Problem, das Lighthouse nicht erfasst.

Q: Brauche ich einen perfekten Score von 100?
A: Nein. Ein Score von 90+ ist ausgezeichnet. Wer 100 hinterherjagt, optimiert oft Dinge, die für Nutzer keine Rolle spielen. Konzentrieren Sie sich auf echte Metriken – LCP, CLS, INP – und ignorieren Sie den Score.

Q: Kann ich Lighthouse vertrauen, wenn ich viele Third-Party-Skripte verwende?
A: Lighthouse markiert Third-Party-Skripte als Problem, kann aber nicht immer zwischen notwendigen und unnötigen Skripten unterscheiden. Verwenden Sie die Audits "Avoid enormous network payloads" und "Reduce JavaScript execution time", um die größten Verursacher zu identifizieren, und entscheiden Sie dann, ob sie es wert sind, behalten zu werden.

Quellen

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org