Lighthouse-Score verbessern: Von rot auf grün

Ein Lighthouse-Score von 95 oder höher wirkt verlockend — und wird häufig als alleiniger Performance-Nachweis herangezogen. Die Realität ist differenzierter: Lighthouse liefert wertvolle Labordaten in einer kontrollierten Umgebung, ersetzt aber keine Feldmessungen. Trotzdem ist ein systematisch verbesserter Lighthouse-Score ein starkes Signal dafür, dass die technische Basis stimmt.

Für Praxiswebsites, die mit WordPress-Themes und Plugin-Kombinationen oft bei 40 bis 60 Punkten starten, ist ein Score über 90 ein realistisches Ziel — mit dem richtigen technischen Ansatz sogar 95 oder höher. Dieser Artikel zeigt, wie Sie jeden Lighthouse-Bereich gezielt verbessern.

Die fünf Lighthouse-Kategorien verstehen

Lighthouse bewertet fünf Bereiche: Performance (Ladegeschwindigkeit und Core Web Vitals im Labor), Accessibility (Barrierefreiheit nach WCAG), Best Practices (Sicherheit, Browser-Kompatibilität, veraltete APIs), SEO (technische SEO-Grundlagen) und bei Progressive Web Apps zusätzlich PWA.

Jede Kategorie hat eigene Audits mit unterschiedlicher Gewichtung. Performance ist für Praxiswebsites meist der prioritäre Bereich, weil er direkt mit Nutzererlebnis und Rankings korreliert. Accessibility und SEO sollten parallel adressiert werden, weil sie überlappen und beide leichter von Anfang an mitzudenken sind als nachträglich zu reparieren.

Wichtig: Lighthouse simuliert ein Moto G Power mit langsamer 4G-Verbindung. Ein Score von 90 im Labor entspricht nicht automatisch guten Felddaten auf allen Geräten und Netzwerken. Beide Perspektiven brauchen Sie.

Performance: Die gewichtigsten Audits

Die Performance-Bewertung basiert auf metrikbasierten Audits, die den Score am stärksten beeinflussen: Total Blocking Time (TBT, Korrelat zu INP), Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), Speed Index und Time to Interactive.

TBT verbessern: JavaScript reduzieren. Jede nicht benötigte Datei entfernen. Verbleibendes JavaScript minifizieren und mit defer/async laden. Long Tasks auf dem Main Thread identifizieren und eliminieren. Bei Astro-Projekten ist TBT typischerweise niedrig, weil standardmäßig kein Client-JavaScript ausgeliefert wird.

LCP verbessern: LCP-Element identifizieren (Lighthouse zeigt es im Audit). Bild optimieren (WebP/AVIF, responsive srcset, preload, fetchpriority=“high”). Serverantwortzeit reduzieren (CDN, statische Generierung). Render-blockierende Ressourcen eliminieren.

CLS verbessern: Bildabmessungen setzen, Webfonts optimieren, dynamische Elemente als Overlay implementieren. Speed Index verbessern: Alles oben genannte plus kritisches CSS inline.

Ein konkretes Beispiel: Eine WordPress-Praxiswebsite mit Lighthouse Performance 45. Nach Migration zu Astro mit optimierten Bildern, CDN und ohne unnötige Plugins: Lighthouse Performance 96. Der Aufwand lohnt sich messbar.

Accessibility: Häufige Lighthouse-Findings

Lighthouse Accessibility prüft über 50 Audits. Die häufigsten Fehler auf Praxiswebsites: Fehlende alt-Attribute auf Bildern. Unzureichender Farbkontrast bei Texten und Buttons. Formularfelder ohne zugeordnete Labels. Fehlende document-title oder lang-Attribut. Überschriften, die nicht in logischer Reihenfolge sind (h1 gefolgt von h3).

Die meisten Accessibility-Findings lassen sich beim initialen Development vermeiden. Semantisches HTML nutzen: button statt div, label mit for-Attribut, nav für Navigation, main für Hauptinhalt. Farbkontraste im Designsystem von Anfang an prüfen, nicht erst im Audit.

Lighthouse Accessibility 100 ist erreichbar, wenn diese Grundlagen stimmen. Ein Score über 90 ist für die meisten Praxiswebsites ein guter Zielwert.

Best Practices: Sicherheit und moderne Standards

Best Practices umfassen HTTPS-Nutzung, keine veralteten JavaScript-Bibliotheken, korrekte Bild-Seitenverhältnisse, keine Browserfehler in der Konsole und sichere Cookie-Attribute.

Häufige Abzüge: Mixed Content (HTTP-Ressourcen auf HTTPS-Seiten). Veraltete JavaScript-Dependencies mit bekannten Sicherheitslücken. Fehlende Content-Security-Policy (CSP). Console Errors durch fehlerhafte Third-Party-Skripte.

Für Praxiswebsites im Gesundheitsbereich ist HTTPS ohnehin Pflicht — sowohl aus Sicherheitsgründen als auch wegen des Vertrauensfaktors. Alle externen Ressourcen (Fonts, Analytics, Maps) über HTTPS einbinden.

SEO-Audit in Lighthouse

Der Lighthouse SEO-Score prüft technische Grundlagen: Meta-Description vorhanden, Links haben beschreibenden Text, Seite ist crawlbar (nicht noindex), robots.txt ist gültig, hreflang korrekt, font-size ausreichend groß für Mobile.

Lighthouse SEO ist kein Ersatz für eine umfassende SEO-Strategie. Es prüft nicht Keyword-Optimierung, Backlink-Profil oder Content-Qualität. Aber ein Score unter 90 deutet auf vermeidbare technische Lücken hin — fehlende Meta-Descriptions, nicht crawlbarer Content, fehlende alt-Texte.

Alle indexierbaren Seiten brauchen eine einzigartige title- und meta-description. Lighthouse prüft das pro Seite — nicht nur auf der Startseite. Bei Praxiswebsites mit 30 oder mehr Seiten empfiehlt sich ein Template-basierter Ansatz, der title und description automatisch aus Seitendaten generiert.

Lighthouse in den Entwicklungsworkflow integrieren

Lighthouse einmalig nach dem Launch zu messen reicht nicht. Performance-Regressionen entstehen durch neue Plugins, aktualisierte Skripte, neue Bilder oder CMS-Änderungen.

Empfohlener Workflow: Lighthouse CI in der Build-Pipeline. Bei jedem Deployment automatisch messen und den Score mit dem vorherigen vergleichen. Schwellenwerte definieren: Performance mindestens 90, Accessibility mindestens 95, SEO mindestens 95. Build failen lassen, wenn Schwellenwerte unterschritten werden.

Lokal: Chrome DevTools → Lighthouse-Tab für schnelle Einzelmessungen. CLI: npx lighthouse https://example.com –output=json für automatisierte Auswertung. PageSpeed Insights API für regelmäßige Monitoring-Messungen.

Bei Praxiswebsites mit geringem Änderungsvolumen reicht eine monatliche Lighthouse-Messung der wichtigsten Seiten: Startseite, Top-3-Leistungsseiten, Kontaktseite. Bei aktivem Blog zusätzlich der neueste Artikel.

Labordaten und Felddaten zusammen denken

Ein perfekter Lighthouse-Score bei schlechten CrUX-Felddaten bedeutet: Die Website ist im Labor schnell, aber nicht für echte Nutzer. Mögliche Ursachen: Third-Party-Skripte verhalten sich im Labor anders als in der Praxis. Geografische Latenz — Labor misst von einem Google-Server, Nutzer sind in ländlichen Gebieten. Gerätevielfalt — Labor simuliert ein Moto G Power, Nutzer haben ältere oder günstigere Geräte.

Die ideale Kombination: Lighthouse Performance über 90 und CrUX-Felddaten im grünen Bereich. Wenn Felddaten fehlen (wenig Traffic), Lighthouse als Proxy nutzen und nach Traffic-Aufbau Felddaten validieren.

Checkliste: Lighthouse-Score verbessern

• Performance: JavaScript reduzieren, Bilder optimieren, CDN nutzen
• LCP-Element identifizieren und gezielt optimieren
• CLS durch feste Abmessungen und Font-Optimierung vermeiden
• Accessibility: alt-Texte, Kontraste, Labels, semantisches HTML
• SEO: title, meta-description, crawlability auf allen Seiten
• HTTPS ohne Mixed Content
• Lighthouse CI in der Build-Pipeline integrieren
• Schwellenwerte definieren und bei Regression alarmieren
• Labordaten und Felddaten (PageSpeed Insights) gemeinsam bewerten

Fazit

Der Lighthouse-Score ist ein nützliches Diagnosewerkzeug — kein Selbstzweck, aber ein klarer Indikator für technische Qualität. Wer Performance, Accessibility und SEO in Lighthouse systematisch adressiert, baut eine Praxiswebsite, die schnell lädt, für alle zugänglich ist und technisch sauber indexiert wird. Bei Monoworks liegt der Lighthouse Performance-Score unserer Projekte typischerweise über 95 — nicht als Marketingzahl, sondern als Ergebnis architektonischer Entscheidungen, die Performance von Anfang an mitdenken.