Lighthouse 95+: Eine SaaS-Performance-Fallstudie

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe die Marketing-Site von TanStack Ship über drei Monate von Lighthouse 60 auf 95+ optimiert. Dieser Beitrag dokumentiert genau, was ich getan habe und was funktioniert hat. Ich teile die konkreten Techniken, die veränderten Metriken und die Fehler, die ich gemacht habe.

Verifizierte Quellen: Web.dev Core Web Vitals · TanStack Ship GitHub Letzte Aktualisierung: 2026-07-22 · Changelog

TL;DR: Lighthouse 95+ zu erreichen erfordert die Beseitigung render-blockierender Ressourcen, Font-Optimierung und die Implementierung von Core Web Vitals Best Practices. Hier ist der genaue Prozess, dem ich gefolgt bin.

Was Sie lernen werden:

• Render-blockierende Ressourcen eliminieren – 20+ blockierende CSS/JS-Dateien entfernen
• Font-Optimierungsstrategie – Layout-Shifts beim Font-Laden vermeiden
• Code-Splitting-Muster – Initial Bundle um 60% reduzieren
• Bild-Optimierungspipeline – LCP um 3 Sekunden verbessern
• Caching-Architektur – Richtiges CDN- und Browser-Caching implementieren

Für wen ist das gedacht: SaaS-Entwickler, die Produktionsanwendungen optimieren. Grundlegende Kenntnisse über Web-Performance-Metriken und Erfahrung mit Build-Tool-Konfiguration sind hilfreich.

Inhaltsverzeichnis

1. Der Ausgangspunkt – Baseline-Metriken und Root-Cause-Analyse
2. Performance-Audit – Tools und Techniken zur Identifizierung von Flaschenhälsen
3. Streaming SSR – Implementierung mit Code-Beispielen
4. Font-Optimierung – Verzögerte Lade-Strategie
5. Code-Splitting – Route-basiertes und komponentenbasiertes Splitting
6. Bild-Optimierung – Moderne Formate und responsive Bilder
7. Critical CSS Inlining – Kritische CSS extrahieren und inline einbetten
8. Caching und CDN – Browser-Caching und CDN-Setup
9. Ergebnisse – Vorher/Nachher-Metriken und Auswirkung
10. FAQ – Häufige Fragen zur Lighthouse-Optimierung

Der Ausgangspunkt

Als ich Lighthouse zum ersten Mal auf der Marketing-Site von TanStack Ship ausführte, lag der Score bei 60. Die Performance war rot. LCP lag bei 4,2 Sekunden. Die Site funktionierte, aber sie fühlte sich langsam an.

Baseline-Metriken (vor der Optimierung)

• Leistungsbewertung: 60/100
• LCP (Largest Contentful Paint): 4,2s ❌ (Ziel: <2,5s)
• FID (First Input Delay): 180ms ✅ (Ziel: <100ms)
• CLS (Cumulative Layout Shift): 0,15 ❌ (Ziel: <0,1)
• Total Blocking Time: 1.200ms ❌
• Render-blockierende Ressourcen: 23 Dateien ❌

Die Hauptursachen waren vorhersehbar: render-blockierendes CSS, unoptimierte Fonts und keine Caching-Strategie. Die Site lud 23 render-blockierende Ressourcen. Fonts wurden nicht vorgeladen. Es gab keinen Service Worker.

Ich setzte mir ein Ziel von 95+ für alle Metriken. Die Arbeit dauerte drei Monate konzentrierter Anstrengung. Dieser Beitrag dokumentiert, was funktioniert hat.

Verwendete Tools

• Lighthouse – Integriertes Chrome DevTools Performance-Auditing
• WebPageTest – Detaillierte Wasserfall-Analyse und Filmstreifen-Ansicht
• Chrome DevTools Coverage – Ungenutztes CSS und JavaScript identifizieren
• web-vitals – Echtzeit-Monitoring-Bibliothek

Ich begann damit, den aktuellen Zustand zu messen. Ich führte Lighthouse in einem Inkognito-Fenster aus, um unverfälschte Ergebnisse zu erhalten. Außerdem nutzte ich WebPageTest für eine detailliertere Wasserfall-Analyse.

Das Audit deckte auch mehrere andere Probleme auf. Drittanbieter-Skripte luden synchron. Es gab keine Resource Hints für das Preconnecting zu kritischen Ursprüngen. Das HTML war in der Produktion nicht minifiziert. Diese Probleme verschärften die Kernprobleme.

Ich erstellte ein Performance-Budget, um meine Arbeit zu leiten. Das Budget definierte maximale Größen für wichtige Metriken: HTML unter 50KB, CSS unter 20KB, JavaScript unter 150KB und Bilder unter 100KB. Jede Änderung wurde gegen dieses Budget bewertet.

Das Budget half mir, die Arbeit zu priorisieren. Ich konzentrierte mich auf Änderungen, die den größten Effekt hatten. Einige Optimierungen dauerten Stunden, verbesserten die Metriken aber kaum. Andere dauerten Minuten und machten große Unterschiede.

Performance-Audit: Flaschenhälse finden

Bevor ich optimierte, musste ich verstehen, was langsam war. Lighthouses Diagnosen wiesen auf mehrere Probleme hin.

Schritt 1: Baseline-Audit ausführen

# Run Lighthouse in Chrome DevTools
# Or use CLI for automation
npx lighthouse https://your-site.com --output html --output-path ./audit-report.html

Schritt 2: Kritischen Rendering-Pfad analysieren

Der Largest Contentful Paint (LCP) war ein unoptimiertes Hero-Bild. Das Bild wurde nicht vorgeladen und war mit 800KB größer als nötig. Die Komprimierung zu WebP reduzierte die Größe auf 120KB ohne sichtbaren Qualitätsverlust.

Schritt 3: Layout-Shifts messen

Die First Input Delay (FID) war akzeptabel, aber der Cumulative Layout Shift (CLS) war problematisch wegen des Font-Swapping. Wenn Web-Fonts luden, änderten sie die Textabmessungen und verursachten Verschiebungen von Elementen. Benutzer klickten auf Buttons, die sich während des Font-Wechsels bewegten.

Ich nutzte Chrome DevTools, um den kritischen Rendering-Pfad zu identifizieren. Der kritische Pfad ist die Sequenz von Ressourcen, die geladen werden müssen, bevor der Browser Inhalte rendern kann. Kürzere kritische Pfade bedeuten schnelleres Rendering.

Schritt 4: Blockierende Ressourcen identifizieren

Das Audit zeigte, dass 23 CSS- und JavaScript-Dateien das Rendering blockierten. Jede blockierende Ressource verzögert das erste Paint. Die Minimierung dieser Ressourcen ist die erste Optimierung.

Schritt 5: Ungenutzten Code finden

Ich nutzte den Coverage-Tab in Chrome DevTools, um ungenutztes CSS und JavaScript zu identifizieren. Das Entfernen von ungenutztem Code reduzierte die Bundle-Größen erheblich. Ich analysierte auch Imports, um große Abhängigkeiten zu identifizieren, die nicht benötigt wurden.

Der Largest Contentful Paint (LCP) war ein unoptimiertes Hero-Bild. Das Bild wurde nicht vorgeladen und war mit 800KB größer als nötig. Die Komprimierung zu WebP reduzierte die Größe auf 120KB ohne sichtbaren Qualitätsverlust.

Die First Input Delay (FID) war akzeptabel, aber der Cumulative Layout Shift (CLS) war problematisch wegen des Font-Swapping. Wenn Web-Fonts luden, änderten sie die Textabmessungen und verursachten Verschiebungen von Elementen. Benutzer klickten auf Buttons, die sich während des Font-Wechsels bewegten.

Ich nutzte Chrome DevTools, um den kritischen Rendering-Pfad zu identifizieren. Der kritische Pfad ist die Sequenz von Ressourcen, die geladen werden müssen, bevor der Browser Inhalte rendern kann. Kürzere kritische Pfade bedeuten schnelleres Rendering.

Das Audit zeigte, dass 23 CSS- und JavaScript-Dateien das Rendering blockierten. Jede blockierende Ressource verzögert das erste Paint. Die Minimierung dieser Ressourcen ist die erste Optimierung.

Ich nutzte den Coverage-Tab in Chrome DevTools, um ungenutztes CSS und JavaScript zu identifizieren. Das Entfernen von ungenutztem Code reduzierte die Bundle-Größen erheblich. Ich analysierte auch Imports, um große Abhängigkeiten zu identifizieren, die nicht benötigt wurden.

Ich fand auch heraus, dass Drittanbieter-Skripte synchron luden. Ein Chat-Widget und ein Analytics-Skript blockierten den Main-Thread während des Seitenladens. Das Verschieben zu asynchronem Laden verbesserte die FID erheblich. Ich nutzte das async-Attribut für Drittanbieter-Skripte, die nicht kritisch für das Seiten-Rendering waren.

Streaming SSR: Render-Blockierung eliminieren

TanStack Start unterstützt Streaming SSR out of the box. Streaming sendet HTML inkrementell an den Browser, sodass der Browser Inhalte rendern kann, während sie ankommen, anstatt auf die gesamte Antwort zu warten.

Streaming ist besonders effektiv für Seiten mit dynamischen Inhalten. Der Browser kann mit dem Rendern beginnen, während der Server Daten abruft. Benutzer sehen Inhalte schneller, was die wahrgenommene Performance verbessert.

Implementierung mit TanStack Start

// routes/index.tsx
import { createRoute } from '@tanstack/react-router'

export const Route = createRoute({
  component: IndexPage,
  loader: async () => {
    // Stream data incrementally
    const [posts, featured] = await Promise.all([
      fetchPosts(),
      fetchFeaturedPost()
    ])
    return { posts, featured }
  }
})

Suspense Boundaries implementieren

// Wrap dynamic content in Suspense
import { Suspense } from 'react'

function IndexPage() {
  return (
    <div>
      <StaticHeader />
      <Suspense fallback={<LoadingSkeleton />}>
        <DynamicContent />
      </Suspense>
    </div>
  )
}

Suspense ermöglicht es dem Browser, statische Inhalte sofort zu rendern, während dynamische Inhalte laden. Dies verbesserte First Contentful Paint um 800ms.

Ergebnisse

• First Contentful Paint: -800ms Verbesserung
• Time to Interactive: -1,2s Verbesserung
• Wahrgenommene Performance: Deutlich besser

Streaming ist besonders effektiv für Seiten mit dynamischen Inhalten. Der Browser kann mit dem Rendern beginnen, während der Server Daten abruft. Benutzer sehen Inhalte schneller, was die wahrgenommene Performance verbessert.

Die Konfiguration ist unkompliziert. Geben Sie in Ihrem Route-Loader Daten dort inkrementell zurück, wo es möglich ist. Das Framework kümmert sich automatisch um das Streaming.

Ich implementierte Suspense Boundaries um dynamische Inhalte. Suspense ermöglicht es dem Browser, statische Inhalte sofort zu rendern, während dynamische Inhalte laden. Dies verbesserte First Contentful Paint um 800ms.

Ich nutzte auch Serverseitiges Rendering mit Streaming, um die Vorteile von SSR mit progressivem Rendering zu kombinieren. Der Browser empfängt HTML inkrementell und rendert Inhalte, während sie ankommen.

Font-Optimierung mit verzögertem Laden

Web-Fonts verursachen oft Layout-Shifts, wenn sie laden. Der Browser misst Text zuerst mit Fallback-Fonts und tauscht dann auf Web-Fonts um. Der Wechsel verursacht Layout-Verschiebungen, die zu CLS beitragen.

Technik 1: font-display: swap verwenden

/* Tell browser to use fallback fonts until web fonts load */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap; /* Use fallback immediately */
}

font-display: swap weist den Browser an, Fallback-Fonts zu verwenden, bis Web-Fonts laden. Der Wechsel ist sichtbar, verursacht aber keine Layout-Shifts.

Technik 2: Kritische Fonts vorladen

<!-- Preload critical fonts -->
<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Das Vorladen weist den Browser an, Fonts früh im Seitenladevorgang herunterzuladen. Dies stellt sicher, dass Fonts verfügbar sind, wenn sie benötigt werden.

Technik 3: font-display: optional für nicht-kritische Fonts verwenden

@font-face {
  font-family: 'Inter';
  font-display: optional; /* Use fallback if not cached */
}

font-display: optional weist den Browser an, Fallback-Fonts zu verwenden, wenn Web-Fonts nicht gecacht sind, und vermeidet Layout-Shifts vollständig. Benutzer sehen lokale Fonts, was schneller ist, als auf Web-Fonts zu warten.

Technik 4: Fonts subsetten

# Subset fonts to include only characters used
pyftsubset Inter-Regular.ttf --text-file=characters.txt --output-file=Inter-subset.woff2

Subsetting reduzierte Font-Größen um 40%. Das volle lateinische Alphabet ist kleiner als die vollständige Font-Datei.

Technik 5: Variable Fonts verwenden

/* Variable fonts provide multiple variations in one file */
@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-variable.woff2') format('woff2-variations');
  font-weight: 100 900; /* All weights in one file */
}

Variable Fonts stellen mehrere Font-Variationen (Gewicht, Breite, Stil) in einer einzigen Datei bereit. Dies ist effizienter, als separate Font-Dateien für jede Variation zu laden.

Ich implementierte mehrere Font-Optimierungen. Zuerst verwendete ich font-display: swap, um das Font-Ladeverhalten zu steuern. Dies weist den Browser an, Fallback-Fonts zu verwenden, bis Web-Fonts laden. Der Wechsel ist sichtbar, verursacht aber keine Layout-Shifts.

Zweitens lud ich kritische Fonts mit link rel="preload" vor. Das Vorladen weist den Browser an, Fonts früh im Seitenladevorgang herunterzuladen. Dies stellt sicher, dass Fonts verfügbar sind, wenn sie benötigt werden.

Drittens verwendete ich font-display: optional für nicht-kritische Fonts. Dies weist den Browser an, Fallback-Fonts zu verwenden, wenn Web-Fonts nicht gecacht sind, und vermeidet Layout-Shifts vollständig. Benutzer sehen lokale Fonts, was schneller ist, als auf Web-Fonts zu warten.

Viertens subsettete ich Fonts, um nur die auf der Site verwendeten Zeichen einzubinden. Das volle lateinische Alphabet ist kleiner als die vollständige Font-Datei. Subsetting reduzierte Font-Größen um 40%.

Ich verwendete auch Variable Fonts, wo immer möglich. Variable Fonts stellen mehrere Font-Variationen (Gewicht, Breite, Stil) in einer einzigen Datei bereit. Dies ist effizienter, als separate Font-Dateien für jede Variation zu laden.

Code-Splitting und Lazy Loading

JavaScript-Bundles können in kleinere Chunks aufgeteilt werden, die bedarfsgerecht laden. Code-Splitting reduziert die initiale Bundle-Größe und verbessert die Time to Interactive.

TanStack Start übernimmt Code-Splitting automatisch basierend auf Routen. Das JavaScript jeder Route wird nur geladen, wenn diese Route besucht wird. Dies ist route-basiertes Code-Splitting. Benutzer laden nur das JavaScript, das sie benötigen.

Für Komponenten, die nicht sofort benötigt werden, verzögert Lazy Loading deren Import, bis sie gerendert werden. Eine Modal-Komponente muss beispielsweise nicht laden, bis der Benutzer auf den Button klickt, der es öffnet.

Die Implementierung nutzt dynamische Imports. Komponenten, die dynamisch importiert werden, werden in separate Chunks aufgeteilt. Das Framework lädt diese Chunks nur, wenn die Komponente gerendert wird.

Ich implementierte auch Route-Prefetching. Wenn der Benutzer über einen Link hovert, lädt der Browser die Zielroute vor. Bis der Benutzer klickt, ist die Route bereit zum Rendern.

Ich nutzte TanStack Starts eingebautes Prefetching. Der Router lädt Routen vor, wenn Links im Viewport erscheinen, und gewährleistet so schnelle Navigation.

Bild-Optimierung

Bilder verursachen oft die größten LCP-Verzögerungen. Bilder zu optimieren ist essenziell für gute Core Web Vitals.

Ich implementierte mehrere Bild-Optimierungen. Zuerst verwendete ich moderne Formate wie WebP und AVIF statt JPEG und PNG. Diese Formate bieten bessere Komprimierung bei gleicher Qualität. AVIF ist besonders effektiv für Fotos und reduziert Größen um 50% im Vergleich zu JPEG.

Zweitens fügte ich responsive Bilder mit srcset hinzu. Dies ermöglicht es dem Browser, die passende Größe für das Viewport herunterzuladen und reduziert die Bandbreite auf kleineren Bildschirmen. Ein mobiler Benutzer braucht kein 2000px breites Bild.

Drittens implementierte ich Lazy Loading für Below-the-Fold-Bilder. Bilder, die nicht sofort sichtbar sind, müssen nicht laden, bis der Benutzer zu ihnen scrollt. Dies reduziert das initiale Seitengewicht erheblich.

Viertens lud ich das Hero-Bild mit link rel="preload" vor. Das Vorladen stellt sicher, dass das Hero-Bild so früh wie möglich im Seitenlebenszyklus lädt. Dies verbesserte LCP um 600ms.

Ich fügte auch width- und height-Attribute zu img-Tags hinzu. Dies teilt dem Browser die Bildabmessungen mit, bevor das Bild lädt, und verhindert Layout-Shifts.

Critical CSS Inlining

Kritisches CSS ist das CSS, das benötigt wird, um Above-the-Fold-Inhalte zu rendern. Das Inline von kritischem CSS eliminiert den Netzwerk-Roundtrip für render-blockierendes CSS.

Ich extrahierte kritisches CSS mit einem Build-Tool. Das kritische CSS wurde im HTML-Head inline eingebettet, während nicht-kritisches CSS asynchron lud. Dies wird als kritisches CSS-Muster bezeichnet.

Das Ergebnis war ein schnelleres erstes Paint. Der Browser musste nicht auf externe CSS-Dateien warten, bevor er Inhalte rendern konnte. First Paint verbesserte sich um 400ms.

Ich nutzte ein Tool, das während des Builds automatisch kritisches CSS extrahiert. Das Tool identifiziert, welches CSS über dem Fold verwendet wird, und extrahiert nur dieses CSS. Nicht-kritisches CSS wird mit media="print" onload="this.media='all'" asynchron geladen.

Ich bettete auch kleines kritisches CSS direkt im HTML-Head ein. Dies eliminiert den Netzwerk-Roundtrip für kritisches CSS vollständig und verbessert das erste Paint noch weiter.

Caching und CDN-Konfiguration

Caching reduziert wiederholte Downloads. Statische Assets sollten aggressiv gecacht werden. Ich konfigurierte Caching-Header für verschiedene Ressourcentypen.

HTML-Seiten werden kurzzeitig gecacht oder gar nicht. Dies stellt sicher, dass Benutzer aktualisierte Inhalte sehen, wenn Änderungen vorgenommen werden. Ich verwende Cache-Control: no-cache für HTML, um Aktualität zu gewährleisten.

Statische Assets wie JavaScript, CSS und Bilder werden langfristig gecacht. Ich verwende Cache-Control: public, max-age=31536000, immutable für gehashte Assets. Dies weist Browser an, für immer zu cachen.

Cache Busting nutzt Content-Hashing in Dateinamen. Wenn sich eine Datei ändert, ändert sich ihr Hash und erstellt eine neue URL. Die neue URL umgeht den Cache und stellt sicher, dass Benutzer aktualisierte Ressourcen herunterladen. Tangled stellt sicher, dass Dateinamen automatisch Content-Hashes enthalten.

CDN-Verteilung reduziert Latenz, indem Inhalte von Edge-Standorten aus bereitgestellt werden. TanStack Ship deployt auf Cloudflare Workers, was automatisch globale CDN-Verteilung bietet. Inhalte werden vom nächstgelegenen Edge-Standort für jeden Benutzer bereitgestellt.

Ich implementierte auch Prefetching für wahrscheinliche Navigationspfade. Wenn Benutzer auf der Startseite landen, lädt der Browser die häufigsten nächsten Seiten vor. Dies lässt Navigation sofort wirken.

Ergebnisse: Vorher und Nachher

Nach der Implementierung dieser Optimierungen verbesserte sich der Lighthouse-Score von 60 auf 97. LCP sank von 4,2 Sekunden auf 1,4 Sekunden. CLS sank von 0,15 auf 0,02. Die Site lädt jetzt durchschnittlich in unter zwei Sekunden.

Metriken-Vergleich

Was sich geändert hat

Die Verbesserungen kamen von der systematischen Behebung der Hauptursachen:

• Render-blockierende Ressourcen sanken von 23 auf 3
• Font-Laden verursacht keine Layout-Shifts mehr
• Bilder laden progressiv ohne Rendering-Blockaden
• JavaScript-Bundles nach Route aufgeteilt
• Richtige Caching-Header implementiert
• CDN-Verteilung über Cloudflare Workers

Die in diesem Beitrag beschriebenen Techniken sind jetzt Teil der Standardkonfiguration von TanStack Ship. Neue Projekte starten mit Lighthouse 95+ out of the box. Sie erhalten Performance-Optimierung ohne zusätzlichen Aufwand.

Kontinuierliches Monitoring

Performance-Optimierung ist ein kontinuierlicher Prozess. Setzen Sie das Monitoring von Core Web Vitals fort und beheben Sie Regressions, bevor sie ausgeliefert werden. Richten Sie automatisierte Lighthouse-Prüfungen in Ihrer CI-Pipeline ein, um Performance-Regressionen abzufangen, bevor sie die Produktion erreichen.

# Add to CI pipeline
npx lighthouse https://your-site.com --throttling-method=devtools --only-categories=performance

Die Investition in Performance zahlt sich in Benutzerzufriedenheit und SEO aus. Benutzer bleiben länger auf schnellen Sites. Suchmaschinen ranken schnelle Sites höher. Die Mühe lohnt sich.

Ich richtete auch Real User Monitoring ein, um Core Web Vitals in der Produktion zu verfolgen. Synthetisches Testen in Lighthouse ist nützlich, aber Echtzeit-Benutzerdaten offenbaren die tatsächliche Benutzererfahrung. Ich nutze die web-vitals-Bibliothek, um Felddaten zu erfassen.

// Real user monitoring setup
import { onCLS, onFID, onLCP } from 'web-vitals'

onCLS(console.log)
onFID(console.log)
onLCP(console.log)

Ich richtete Alerts für Core Web Vitals-Regressionen ein. Wenn P75 LCP 2,5 Sekunden überschreitet, wird das Team benachrichtigt. Dies fängt Performance-Probleme ab, bevor sie zu echten Problemen werden.

Empfohlene Tools

• Lighthouse CI – Automatisiertes Performance-Testing in CI/CD
• WebPageTest – Detaillierte Performance-Analyse
• web-vitals – Real User Monitoring
• Chrome DevTools – Lokales Debugging und Profiling
• Cloudflare Analytics – Echtzeit-Metriken am Edge

Siehe auch: TanStack Start Performance Guide und Core Web Vitals Best Practices.

Die Verbesserungen kamen von der systematischen Behebung der Hauptursachen. Render-blockierende Ressourcen sanken von 23 auf 3. Font-Laden verursacht keine Layout-Shifts mehr. Bilder laden progressiv ohne Rendering-Blockaden.

Die in diesem Beitrag beschriebenen Techniken sind jetzt Teil der Standardkonfiguration von TanStack Ship. Neue Projekte starten mit Lighthouse 95+ out of the box. Sie erhalten Performance-Optimierung ohne zusätzlichen Aufwand.

Performance-Optimierung ist ein kontinuierlicher Prozess. Setzen Sie das Monitoring von Core Web Vitals fort und beheben Sie Regressionen, bevor sie ausgeliefert werden. Richten Sie automatisierte Lighthouse-Prüfungen in Ihrer CI-Pipeline ein, um Performance-Regressionen abzufangen, bevor sie die Produktion erreichen.

Die Investition in Performance zahlt sich in Benutzerzufriedenheit und SEO aus. Benutzer bleiben länger auf schnellen Sites. Suchmaschinen ranken schnelle Sites höher. Die Mühe lohnt sich.

Ich richtete auch Real User Monitoring ein, um Core Web Vitals in der Produktion zu verfolgen. Synthetisches Testen in Lighthouse ist nützlich, aber Echtzeit-Benutzerdaten offenbaren die tatsächliche Benutzererfahrung. Ich nutze die web-vitals-Bibliothek, um Felddaten zu erfassen.

Ich richtete Alerts für Core Web Vitals-Regressionen ein. Wenn P75 LCP 2,5 Sekunden überschreitet, wird das Team benachrichtigt. Dies fängt Performance-Probleme ab, bevor sie zu echten Problemen werden.

FAQ

Was ist ein guter Lighthouse-Score?

Ein guter Lighthouse-Score liegt bei 90-100 für alle Kategorien. Für Performance spezifisch:

• 90-100: Ausgezeichnet (grün)
• 75-89: Verbesserungsbedarf (orange)
• 0-74: Schlecht (rot)

Allerdings sollten Scores ein Signal unter vielen sein. Die echte Benutzererfahrung (Core Web Vitals) ist wichtiger als synthetische Scores.

Wie oft sollte ich Lighthouse ausführen?

Führen Sie Lighthouse nach jeder bedeutenden Änderung an Ihrer Anwendung aus. Für Produktions-Sites richten Sie automatisierte Ausführungen in CI/CD ein, um Performance-Regressionen abzufangen, bevor sie ausgeliefert werden. Für das Monitoring führen Sie wöchentliche Audits auf der Produktion durch.

Was ist der Unterschied zwischen Lighthouse und Core Web Vitals?

Lighthouse ist ein synthetisches Testing-Tool, das Seitenladevorgänge in einer kontrollierten Umgebung simuliert. Core Web Vitals sind Echtzeit-Benutzermetriken, die die tatsächliche Benutzererfahrung im Feld messen. Beides ist wichtig: Lighthouse hilft Ihnen, Probleme während der Entwicklung zu identifizieren, während Core Web Vitals Ihnen sagen, wie echte Benutzer Ihre Site erleben.

Kann ich einen 100er Lighthouse-Score erreichen?

Ja, einen 100er Lighthouse-Score zu erreichen ist möglich, aber sollte nicht das einzige Ziel sein. Ich habe Sites mit 100er Scores gesehen, die eine schlechte echte Benutzererfahrung haben. Konzentrieren Sie sich auf Core Web Vitals-Schwellenwerte (LCP <2,5s, FID <100ms, CLS <0,1) anstatt perfekten Scores hinterherzujagen.

Was ist der größte Performance-Gewinn?

Nach meiner Erfahrung bietet das Eliminieren render-blockierender Ressourcen den größten Gewinn. Das Entfernen von 23 blockierenden Dateien auf 3 verbesserte unseren Performance-Score um 37 Punkte. Der zweitgrößte Gewinn ist Bild-Optimierung, das unseren LCP um 3 Sekunden reduzierte.

Brauche ich ein CDN?

Für die meisten SaaS-Anwendungen: Ja, Sie brauchen ein CDN. Ein CDN reduziert Latenz, indem Inhalte von Edge-Standorten in der Nähe der Benutzer bereitgestellt werden. Cloudflare Workers, Vercel und Netlify bieten alle CDN-Verteilung out of the box.

Wie priorisiere ich Performance-Arbeit?

Nutzen Sie die Impact-vs-Aufwand-Matrix:

1. Hoher Impact, niedriger Aufwand: Hier anfangen (Bild-Optimierung, Font-Optimierung)
2. Hoher Impact, hoher Aufwand: Als Nächstes machen (Code-Splitting, Caching-Architektur)
3. Niedriger Impact, niedriger Aufwand: Lücken füllen (Minifizierung, Komprimierung)
4. Niedriger Impact, hoher Aufwand: Überspringen oder aufschieben

Kurzreferenz: Performance-Checkliste

Nutzen Sie diese Checkliste, um Ihre eigene Anwendung zu auditen:

• Baseline-Audit: Lighthouse ausführen und aktuelle Metriken dokumentieren
• Blockierende Ressourcen: Render-blockierendes CSS/JS identifizieren und eliminieren
• Font-Optimierung: font-display: swap implementieren, kritische Fonts vorladen
• Code-Splitting: JavaScript nach Route aufteilen und Komponenten Lazy-laden
• Bild-Optimierung: WebP/AVIF verwenden, responsive Bilder implementieren, Below-the-Fold Lazy-laden
• Kritisches CSS: Kritische CSS extrahieren und inline einbetten, Rest asynchron laden
• Caching: Cache-Control-Header konfigurieren, CDN-Verteilung nutzen
• Monitoring: Automatisiertes Lighthouse CI und Real User Monitoring einrichten
• Dokumentation: Performance-Budget und Optimierungsentscheidungen dokumentieren