Performance-Score: Von Ladezeiten zu Rankings
Der Performance-Score ist der gewichtigste der vier Kategorien, weil er direkt mit den Core Web Vitals verknüpft ist. Er setzt sich aus fünf Metriken zusammen, die unterschiedlich stark gewichtet werden:
| Metrik | Gewichtung | Gut | Beschreibung |
|---|---|---|---|
| Total Blocking Time (TBT) | 30 % | < 200 ms | Summe aller Long Tasks (INP-Proxy) |
| Largest Contentful Paint (LCP) | 25 % | < 2.5 s | Ladezeit des größten Inhaltselements |
| Cumulative Layout Shift (CLS) | 25 % | < 0.1 | Summe unerwarteter Layout-Verschiebungen |
| First Contentful Paint (FCP) | 10 % | < 1.8 s | Erster sichtbarer Inhalt |
| Speed Index | 10 % | < 3.4 s | Wie schnell Inhalte sichtbar werden |
Render-blockierende Ressourcen eliminieren
CSS- und JavaScript-Dateien im Head-Bereich ohne async oder defer blockieren das Rendering. Der Browser wartet mit der Darstellung, bis diese Dateien vollständig geladen und verarbeitet sind. Das ist einer der häufigsten Gründe für niedrige Performance-Scores.
- Kritisches CSS inline: Extrahieren Sie das CSS für den sichtbaren Bereich (Above the Fold) und betten Sie es direkt im
<head>ein - Unkritisches CSS asynchron: Laden Sie restliches CSS mit
media="print" onload="this.media='all'"oder per JavaScript - JavaScript mit defer: Verwenden Sie das
defer-Attribut für alle nicht-kritischen Scripts - Modules statt Scripts:
type="module"bringt automatisch defer-Verhalten mit
Bilder optimieren: Der größte Hebel
Nicht optimierte Bilder sind der häufigste Einzelfaktor für schlechte Performance-Scores. Lighthouse identifiziert Bilder, die in modernen Formaten deutlich kleiner wären. Laut HTTP Archive machen Bilder durchschnittlich 42 % des Seitengewichts aus (HTTP Archive).
- WebP oder AVIF mit JPEG/PNG-Fallback über das
<picture>-Element - Explizite
width- undheight-Attribute, um CLS zu vermeiden loading="lazy"für Below-the-Fold-Bilder,fetchpriority="high"für das LCP-Elementsrcsetundsizesfür responsive Bildauslieferung- Komprimierung: Qualität 75-85 für JPEG, automatische Optimierung mit Build-Tools
Eine ausführliche Anleitung zu Bildoptimierung und weiteren Ladezeitfaktoren finden Sie im Ladezeit-Optimierungsguide.
JavaScript reduzieren und aufteilen
Große JavaScript-Bundles belasten den Main Thread und verschlechtern TBT und damit den INP-Wert. Lighthouse zeigt an, wie viel ungenutztes JavaScript geladen wird. Typische Maßnahmen sind Code-Splitting, Tree-Shaking, Ersetzen schwerer Bibliotheken durch leichtere Alternativen und das konsequente Entfernen nicht mehr genutzter Plugins.
Schriftarten performant laden
Web Fonts verursachen häufig sowohl Performance- als auch CLS-Probleme. Hosten Sie Schriften lokal statt von externen Servern, was auch DSGVO-Probleme mit Google Fonts vermeidet. Verwenden Sie font-display: swap, Preload-Hints für die wichtigsten Font-Dateien und das WOFF2-Format für optimale Kompression.
Accessibility-Score: Barrierefreiheit als Qualitätsmerkmal
Der Accessibility-Score prüft, ob Ihre Website für Menschen mit Behinderungen zugänglich ist. Seit dem BFSG (Barrierefreiheitsstärkungsgesetz) ist Barrierefreiheit für viele Websites auch rechtlich relevant. Lighthouse testet einen Teil der WCAG-2.1-AA-Anforderungen automatisch.
Kontrastverhältnisse
Text muss ein Kontrastverhältnis von mindestens 4,5:1 zum Hintergrund aufweisen (3:1 für großen Text). Hellgraue Texte auf weißem Hintergrund sind der häufigste Kontrast-Fehler. Lighthouse prüft jedes Textelement und zeigt exakte Kontrastwerte und WCAG-Konformität an.
Alt-Texte für Bilder
Jedes informative Bild benötigt einen beschreibenden alt-Text. Rein dekorative Bilder sollten ein leeres alt=""-Attribut haben, damit Screenreader sie überspringen. Lighthouse markiert Bilder ohne alt-Attribut und Bilder, deren alt-Text leer ist, obwohl sie informativen Charakter haben.
Weitere Accessibility-Punkte
- Überschriften-Hierarchie: h1 bis h6 in logischer Reihenfolge ohne übersprungene Ebenen
- Fokus-Indikatoren: Interaktive Elemente müssen bei Tastatur-Navigation sichtbar fokussierbar sein. Entfernen Sie niemals
outline: noneohne gleichwertige Alternative. - ARIA-Labels: Formularfelder ohne sichtbares Label benötigen
aria-labeloderaria-labelledby - Sprachattribut: Das
<html>-Element muss ein gültigeslang-Attribut haben - Link-Texte: Vermeiden Sie generische Linktexte wie "hier klicken". Verwenden Sie beschreibende Texte, die auch ohne Kontext verständlich sind.
- Tastatur-Navigation: Alle interaktiven Elemente müssen per Tab erreichbar und mit Enter/Space bedienbar sein
Lighthouse kann nur rund 30-40 % der WCAG-Anforderungen automatisch prüfen (Deque Systems). Komplexere Aspekte wie Screenreader-Kompatibilität und kognitive Zugänglichkeit erfordern manuelle Tests. Das XICTRAQ Compliance-Modul integriert automatisierte Barrierefreiheits-Prüfungen als Teil des kontinuierlichen Monitorings.
Best-Practices-Score: Webstandards einhalten
Der Best-Practices-Score prüft allgemeine Webentwicklungsstandards. Die meisten Punkte lassen sich durch saubere Entwicklungspraktiken und aktuelle Konfigurationen erreichen.
- HTTPS: Alle Ressourcen müssen über HTTPS geladen werden. Mixed Content (HTTP-Ressourcen auf HTTPS-Seiten) ist ein sofortiger Punktabzug. Das SSL-Monitoring von XICTRAQ stellt sicher, dass Zertifikate rechtzeitig erneuert werden.
- Keine veralteten APIs: Vermeiden Sie
document.write(),navigator.userAgent-Sniffing und andere veraltete Techniken - Keine Konsolen-Fehler: JavaScript-Fehler in der Browser-Konsole werden als Qualitätsproblem gewertet
- Korrekte Bildformate: Bilder sollten das effizienteste Format für ihren Inhalt verwenden
- Security Headers: Content-Security-Policy, X-Content-Type-Options und andere Sicherheits-Header verbessern den Score
- Keine anfälligen JavaScript-Bibliotheken: Lighthouse prüft auf bekannte Sicherheitslücken in eingebundenen Libraries
SEO-Score: Technische Grundlagen für Sichtbarkeit
Der SEO-Score prüft technische Voraussetzungen für gute Suchmaschinenplatzierungen. Ein Score von 100 bedeutet, dass die technischen Grundlagen stimmen, nicht dass die Seite automatisch gut rankt. Inhaltliche Relevanz bleibt der wichtigste Faktor.
- Meta-Tags: Jede Seite braucht einen einzigartigen
<title>(50-60 Zeichen) und eine<meta name="description">(120-160 Zeichen) - Mobile Optimierung: Viewport-Meta-Tag, responsive Design, ausreichend große Touch-Targets (mindestens 48x48 px)
- Crawlbarkeit: Valide robots.txt, keine unbeabsichtigten noindex-Direktiven, funktionierende Sitemap
- Strukturierte Daten: Schema.org-Markup für Rich Snippets in den Suchergebnissen
- Canonical-Tags: Eindeutige Canonical-URLs, um Duplicate Content zu vermeiden
- HTTPS: Google bevorzugt sichere Seiten in den Rankings
- hreflang: Korrekte Sprachzuordnung bei mehrsprachigen Websites
Für eine umfassende technische SEO-Überwachung, die über den Lighthouse-SEO-Score hinausgeht, bietet XICTRAQ ein dediziertes SEO-Monitoring-Modul. Mehr dazu im Artikel über automatisiertes technisches SEO-Monitoring.
Typische Score-Killer und schnelle Lösungen
| Problem | Kategorie | Score-Verlust | Lösung |
|---|---|---|---|
| Nicht optimierte Bilder | Performance | 10-30 Punkte | WebP/AVIF, Kompression, srcset |
| Render-blockierendes CSS/JS | Performance | 10-20 Punkte | Critical CSS, defer, async |
| Fehlende Alt-Texte | Accessibility | 5-15 Punkte | Beschreibende alt-Attribute |
| Unzureichende Kontraste | Accessibility | 5-10 Punkte | Kontrastverhältnis 4.5:1+ |
| Mixed Content | Best Practices | Sofort rot | Alle Ressourcen auf HTTPS |
| Fehlende Meta-Description | SEO | 5-10 Punkte | Einzigartige Description pro Seite |
| Keine viewport-Meta | SEO | 10+ Punkte | viewport meta-Tag im Head |
| Veraltete JS-Libraries | Best Practices | 5-15 Punkte | Libraries aktualisieren |
Score-Schwankungen richtig interpretieren
Lighthouse-Scores schwanken naturgemäss zwischen den Messungen. Server-Auslastung, Netzwerkbedingungen und Browser-Extensions beeinflussen das Ergebnis. Ein Score von 92 bei einer Messung und 88 bei der nächsten ist normal und bedeutet nicht zwingend eine Verschlechterung.
Entscheidend ist der Trend über die Zeit. XICTRAQ sammelt Messwerte über Wochen und Monate und stellt den Verlauf grafisch dar. Ein schleichender Abfall über drei Wochen ist aussagekräftiger als ein einzelner niedriger Wert. Die Reporting-Funktion erstellt automatisierte Berichte, die Score-Veränderungen im Kontext zeigen.
Für konsistentere Lighthouse-Ergebnisse: Testen Sie im Inkognito-Modus ohne Extensions, verwenden Sie eine stabile Netzwerkverbindung, und führen Sie mehrere Messungen durch. Lighthouse CI automatisiert diesen Prozess und berechnet Medianwerte über mehrere Läufe.
Lighthouse in den Entwicklungsprozess integrieren
Lighthouse CI in der Build-Pipeline
Lighthouse CI führt automatisierte Audits in Ihrer CI/CD-Pipeline durch. Sie definieren Schwellenwerte für jeden Score und der Build scheitert, wenn die Werte unterschritten werden. So werden Performance-Regressionen erkannt, bevor sie in die Produktion gelangen.
{
"ci": {
"assert": {
"assertions": {
"categories:performance": ["error", { "minScore": 0.9 }],
"categories:accessibility": ["error", { "minScore": 0.9 }],
"categories:best-practices": ["warn", { "minScore": 0.95 }],
"categories:seo": ["error", { "minScore": 1.0 }]
}
}
}
}Entwicklung und Produktion ergänzen sich
Lighthouse in der CI/CD-Pipeline überwacht die Entwicklungsumgebung. XICTRAQ überwacht die Produktionsumgebung. Beide sind notwendig, weil manche Probleme nur in der Produktion auftreten, etwa durch CDN-Fehlkonfigurationen, Traffic-Spitzen oder externe Script-Änderungen. Die Kombination aus Pre-Deployment-Checks und kontinuierlichem Monitoring bietet den besten Schutz vor Score-Regressionen.
Realistische Ziele setzen
Nicht jede Website kann einen Score von 100 in allen Kategorien erreichen. Dynamische Seiten mit vielen externen Integrationen haben naturgemäss höhere Anforderungen als statische Landingpages. E-Commerce-Shops mit Dutzenden Tracking-Scripts werden den Performance-Score einer statischen Firmenseite nie erreichen.
Score 95-100 realistisch. Wenig JavaScript, optimierte Bilder und saubere Struktur reichen für Spitzenwerte.
Score 80-95 realistisch. Plugin-Overhead und dynamische Inhalte begrenzen das Maximum. Fokus auf Caching und Bildoptimierung.
Score 70-90 realistisch. Tracking-Scripts, Produktbilder und dynamische Inhalte fordern die Performance. Quick Wins bei Bildern und JavaScript.
Score variabel. SSR/SSG verbessert LCP drastisch. Code-Splitting und Tree-Shaking für gute TBT-Werte.
Checkliste: Alle vier Kategorien optimieren
- Performance: Bilder in WebP/AVIF, Critical CSS inline, JavaScript mit defer, Preload für LCP-Element
- Accessibility: Alt-Texte für alle Bilder, Kontrast 4.5:1+, Fokus-Indikatoren, semantisches HTML
- Best Practices: HTTPS für alle Ressourcen, keine veralteten APIs, Security Headers, aktuelle Libraries
- SEO: Einzigartige Title + Description, viewport-Meta, valide robots.txt, Canonical-Tags, Structured Data
Lighthouse-Scores automatisiert überwachen
Ein einmaliger Lighthouse-Test liefert eine Momentaufnahme. Doch Scores verändern sich mit jedem Deployment, Plugin-Update und Content-Änderung. XICTRAQ führt regelmäßige Lighthouse-Audits durch und zeichnet die Score-Entwicklung über Wochen und Monate auf.
Die Performance-Daten werden im Kontext weiterer XICTRAQ-Module wie Uptime-Monitoring, Security-Analyse, DSGVO-Compliance und SEO-Monitoring dargestellt. So erkennen Sie Zusammenhänge: Fällt der Performance-Score nach einem bestimmten Deployment? Verschlechtert ein neues Third-Party-Script den Best-Practices-Score?
Starten Sie jetzt mit einer kostenlosen Demo oder registrieren Sie sich, um Ihre Lighthouse-Scores dauerhaft im Blick zu behalten und Score-Regressionen sofort zu erkennen.
Was ist ein guter Lighthouse-Score?
Beeinflusst der Lighthouse-Score direkt das Google-Ranking?
Warum schwanken meine Lighthouse-Scores?
Kann ich 100/100 in allen Kategorien erreichen?
Wie oft sollte ich Lighthouse-Tests durchführen?
Reicht Lighthouse allein für die Performance-Bewertung?
Dieser Artikel basiert auf Daten von: Core Web Vitals (Google), (HTTP Archive).