Wenn eine Website langsam lädt, schlechte SEO-Werte hat oder für Screenreader unzugänglich ist, lässt sich das mit einem einzigen Tool in Minuten diagnostizieren: Google Lighthouse. Das Open-Source-Audit-Tool ist direkt in Chrome DevTools integriert, läuft als Node.js-CLI und steckt hinter dem bekannten PageSpeed Insights-Dienst. Dieser Artikel erklärt, wie Lighthouse funktioniert, wie man die Ergebnisse richtig interpretiert und was die häufigsten Probleme verursacht.

Was ist Lighthouse und wo läuft es?

Lighthouse ist ein automatisiertes Audit-Framework, das eine Webseite in einem simulierten Browser lädt und anschließend Hunderte von Prüfungen ausführt. Das Ergebnis ist ein strukturierter Bericht mit Scores zwischen 0 und 100 in fünf Kategorien. Je nach Einsatzort gibt es leichte Unterschiede:

Chrome DevTools: Aufruf über F12 → Tab „Lighthouse". Läuft im lokalen Browser, berücksichtigt also auch Cookies, Login-Zustände und lokale Server. Ideal für die Entwicklung.
CLI: npm install -g lighthouse, dann lighthouse https://example.com --output html. Ermöglicht Scripting, benutzerdefinierte Flags und CI/CD-Integration.
PageSpeed Insights: Google führt Lighthouse auf seinen Servern aus und liefert sowohl Lab-Daten (simuliert) als auch Field-Daten (echte Nutzerdaten aus dem Chrome User Experience Report).

Die 5 Audit-Kategorien

Lighthouse-Kategorien und ihre Bedeutung
Kategorie	Was wird gemessen	Gewichtung im Score	Relevant für
Performance	Ladezeit, Rendering-Geschwindigkeit, Interaktivität	Einzelne Metriken gewichtet (s. u.)	UX, Core Web Vitals, Google-Ranking
Accessibility	ARIA, Kontrast, Tastaturnavigation, Semantik	Alle Audits gleichwertig	Barrierefreiheit, BITV, WCAG
Best Practices	HTTPS, veraltete APIs, Sicherheits-Header, Konsole	Alle Audits gleichwertig	Sicherheit, moderne Webstandards
SEO	Meta-Tags, robots.txt, canonical, strukturierte Daten	Alle Audits gleichwertig	Suchmaschinen-Indexierung
PWA	Manifest, Service Worker, HTTPS, Icons	Alle Audits gleichwertig	Progressive Web Apps

Den Performance-Score verstehen

Der Performance-Score ergibt sich aus einem gewichteten Durchschnitt von sechs Metriken, die alle auf realen Nutzerdaten des HTTP Archive basieren:

FCP (First Contentful Paint): Wann erscheint der erste sichtbare Inhalt? Gewichtung: 10 %
LCP (Largest Contentful Paint): Wann ist das größte Element sichtbar? Core Web Vital – Gewichtung: 25 %
TBT (Total Blocking Time): Summe aller Zeiträume, in denen der Hauptthread blockiert war. Proxy für INP. Gewichtung: 30 %
CLS (Cumulative Layout Shift): Wie stark verschiebt sich das Layout unerwartet? Core Web Vital – Gewichtung: 25 %
SI (Speed Index): Wie schnell wird der Viewport visuell befüllt? Gewichtung: 10 %

Ein Score von 90–100 gilt als grün (gut), 50–89 als orange (verbesserungswürdig), unter 50 als rot (schlecht). Wichtig: Der Score ist eine Momentaufnahme und kann je nach Netzwerk, Geräteleistung und externen Ressourcen variieren. Mehrere Messungen mitteln ist empfehlenswert.

Häufige Performance-Probleme und ihre Lösungen

Typische Lighthouse-Warnungen und Fixes
Problem	Audit-Name	Typischer Fix
Zu große Bilder	Properly size images	Responsive Images mit srcset, WebP/AVIF nutzen
Render-Blocking CSS/JS	Eliminate render-blocking resources	Critical CSS inlinen, Scripts mit defer/async laden
Fehlender Browser-Cache	Serve static assets with efficient cache policy	Cache-Control-Header mit langer max-age setzen
Unkomprimierte Ressourcen	Enable text compression	Gzip oder Brotli auf dem Server aktivieren
Kein CDN / langsame TTFB	Server response times (TTFB)	CDN einsetzen, Server-seitiges Caching (Redis)
Layout Shifts	Avoid large layout shifts	Bildgrößen (width/height) im HTML angeben

Tipp: Führe den Lighthouse-Audit immer im Inkognito-Modus durch, wenn du DevTools nutzt. Browser-Erweiterungen (Werbeblocker, Passwort-Manager) können Messergebnisse verfälschen und falsch-positive Best-Practices-Fehler auslösen.

Den Accessibility-Audit nutzen

Lighthouse prüft Barrierefreiheit mit der axe-core-Engine. Geprüft werden unter anderem:

Kontrastverhältnisse für Text (WCAG AA: 4,5:1)
ARIA-Attribute: Fehlende aria-label bei Icons ohne sichtbarem Text, ungültige Rollen
Formular-Labels: Jedes <input> braucht ein zugehöriges <label>
Alt-Texte: Bilder ohne alt-Attribut werden als Fehler markiert
Dokumentstruktur: Korrekte Überschriften-Hierarchie (kein Sprung von h1 zu h3)

Lighthouse findet automatisierbar etwa 30–40 % aller WCAG-Verstöße. Für eine vollständige Prüfung ist manuelles Testen (z. B. mit NVDA, VoiceOver oder dem axe DevTools-Plugin) unverzichtbar.

Die SEO-Checkliste in Lighthouse

Der SEO-Bericht prüft technische Grundlagen, keine inhaltliche Qualität. Typische Punkte:

Vorhandensein und Länge des <title>-Tags
meta name="description" gesetzt und nicht zu lang
rel="canonical" korrekt gesetzt
Seite nicht mit noindex blockiert
Links haben erkennbaren Text (kein „Hier klicken")
robots.txt vorhanden und valide
Dokument hat kein Tap-Target-Problem (zu kleine Buttons auf Mobilgeräten)

Achtung: Ein Lighthouse-SEO-Score von 100 bedeutet nicht, dass die Seite gut rankt – er bedeutet nur, dass keine technischen Grundlagenprobleme vorliegen. Content-Qualität, Backlinks und E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) wertet Lighthouse nicht aus.

CI/CD-Integration mit Lighthouse CI

Lighthouse CI ist das offizielle Tool, um Lighthouse-Audits in Continuous-Integration-Pipelines zu integrieren. Nach der Installation mit npm install -g @lhci/cli fügt man eine lighthouserc.json ins Projekt ein und definiert Mindest-Scores als Assertions:

{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "categories:accessibility": ["error", {"minScore": 0.95}]
      }
    }
  }
}

Unterschreitet ein Deployment die definierten Schwellenwerte, schlägt der CI-Build fehl. So verhindert man Performance-Regressionen, bevor sie in der Produktion landen.

FAQ: Google Lighthouse

Warum schwanken meine Lighthouse-Scores zwischen zwei Messungen?: Lighthouse misst in einer simulierten Umgebung mit künstlich gedrosseltem Netzwerk und CPU. Externe Faktoren wie Serverantwortzeiten, variierendes CDN-Caching und Hintergrundprozesse des Computers beeinflussen jeden Lauf. Google empfiehlt, mindestens drei Messungen durchzuführen und den Median zu verwenden.
Was ist der Unterschied zwischen Lab-Daten und Field-Daten in PageSpeed Insights?: Lab-Daten stammen aus einem Lighthouse-Lauf in einer kontrollierten Umgebung (simuliertes Gerät, konstante Netzwerkbedingungen). Field-Daten (CrUX) basieren auf echten Messwerten von Chrome-Nutzern der letzten 28 Tage. Bei Diskrepanzen sind die Field-Daten für Google-Rankings relevanter.
Kann ich Lighthouse für Seiten hinter einem Login ausführen?: Ja, über Chrome DevTools DevTools → Lighthouse lässt sich ein Audit im eingeloggten Zustand durchführen, da der lokale Browser-Kontext (Cookies, Session) verwendet wird. Die CLI unterstützt außerdem Custom Headers und Cookie-Flags für automatisierte Audits hinter Auth.
Wie verbessere ich schnell den CLS-Wert?: Der häufigste Auslöser für hohen CLS sind Bilder und Videos ohne explizite width- und height-Attribute sowie eingebettete Werbebanner, die sich nach dem Laden verschieben. Setze immer Dimensionen im HTML, nutze aspect-ratio in CSS und reserviere Platz für dynamisch geladene Inhalte mit Skeleton-Screens.

Google Lighthouse – Website-Audit für Performance und SEO