Frontend-Performance-Audit mit Lighthouse

Lighthouse ist das quelloffene Audit-Tool von Google, das eine Webseite automatisch in den Bereichen Performance, Barrierefreiheit, Best Practices und SEO bewertet. Doch die meisten werfen nur einen Blick auf diesen runden Performance-Score und geraten in Panik. Der Score ist lediglich eine Zusammenfassung der eigentlichen Geschichte. In diesem Artikel zeige ich dir, wie du den Bericht wirklich liest, welche Metriken die Nutzererfahrung tatsächlich prägen und wie du die gefundenen Engpässe Schritt für Schritt behebst.

Einen Lighthouse-Bericht ausführen

Es gibt mehrere Wege zu Lighthouse; richtig ist der, der zu deinem Anwendungsfall passt:

• Chrome DevTools > Tab Lighthouse: schnell, visuell und lokal ausgeführt. Der Haken: CPU und Netzwerk deines Rechners beeinflussen das Ergebnis.
• PageSpeed Insights (pagespeed.web.dev): nutzt dieselbe Engine, läuft aber auf Googles Servern und zeigt zusätzlich Daten echter Nutzer (CrUX / Field Data).
• CLI: ideal für die Automatisierung. Der Befehl npx lighthouse https://aslain.dev --view erzeugt den Bericht und öffnet ihn im Browser.

Ein wichtiger Punkt: Miss immer in einem Inkognito-Fenster mit deaktivierten Erweiterungen. Werbeblocker und andere Add-ons injizieren Code in die Seite und verfälschen den Score. Verlasse dich auch nicht auf eine einzige Messung; Performance schwankt, führe sie 3 bis 5 Mal aus und betrachte den Median.

Labordaten oder Felddaten?

Lighthouse bietet zwei Arten von Daten, und sie zu verwechseln ist der häufigste Fehler. Labordaten (DevTools/Lighthouse) messen einen einzelnen Ladevorgang in einer kontrollierten, simulierten Umgebung; reproduzierbar, aber künstlich. Felddaten (Core Web Vitals) sind anonymisierte Messungen, die über Chrome von Nutzern gesammelt werden, die deine Seite in den letzten 28 Tagen tatsächlich besucht haben. Für das Ranking berücksichtigt Google die Felddaten. Selbst wenn dein Laborwert 100 beträgt, bedeuten schlechte Felddaten, dass das eigentliche Problem ungelöst bleibt.

Welche Metriken zählen: LCP, CLS und TBT

Der Performance-Score ist ein gewichteter Mittelwert; diese Metriken tragen am meisten bei:

• LCP (Largest Contentful Paint): wie lange das größte sichtbare Element (meist das Hero-Bild oder die Überschrift) zum Rendern braucht. Ziel: unter 2,5 s.
• CLS (Cumulative Layout Shift): unerwartetes Verschieben von Elementen während des Ladens. Ziel: unter 0,1.
• TBT (Total Blocking Time): wie lange der Haupt-Thread durch JavaScript für Nutzerinteraktion blockiert ist. Sein Feld-Pendant ist INP. Ziel: unter 200 ms.
• FCP und Speed Index: die Geschwindigkeit des ersten Inhalts und des visuellen Aufbaus.

Lies die Farbe neben jeder Metrik (grün/orange/rot) zusammen mit den Abschnitten „Opportunities" und „Diagnostics". Es sind diese Punkte, nicht der Score selbst, die dir sagen, was zu tun ist.

Den LCP-Engpass beheben

LCP entsteht meist durch ein großes Bild oder eine zu spät geladene Webschrift. Praktische Schritte:

• Konvertiere das Hero-Bild in ein modernes Format (WebP/AVIF) und liefere es in der richtigen Größe aus. Schick kein 3000px breites Bild in einen 800px-Platz.
• Gib dem Browser einen Hinweis, damit er das kritische Bild früh entdeckt:

<link rel="preload" as="image"
      href="/img/hero.avif"
      fetchpriority="high">

Verwende für Schriften font-display: swap, damit der Text nicht unsichtbar bleibt, während die Schrift lädt. Die Server-Antwortzeit (TTFB) beeinflusst LCP ebenfalls direkt; cache schwere Abfragen und nutze nach Möglichkeit ein CDN. Diese wenigen Punkte haben in der Regel große Wirkung, aber die Reihenfolge variiert je nach Seite — öffne das LCP-Element, auf das der Bericht zeigt, und finde die wahre Ursache.

CLS und TBT senken

Für CLS gilt die goldene Regel: Reserviere vorab Platz für jedes Element. Füge Bildern width- und height-Attribute hinzu (der Browser berechnet das Verhältnis und reserviert Platz), gib Werbe-/Embed-Plätzen eine feste Höhe und vermeide spät geladene Banner, die den Inhalt nach unten schieben. Um durch Webschriften verursachte Verschiebungen zu verringern, helfen size-adjust und eine abgestimmte Fallback-Schrift.

TBT ist fast immer ein JavaScript-Überschuss. Was zu tun ist:

• Entferne ungenutztes JS; nimm die Warnung „Reduce unused JavaScript" ernst.
• Lade Skripte von Drittanbietern (Analytics, Chat, Werbung) mit async oder defer und verschiebe sie nach Möglichkeit auf die Zeit nach der Interaktion.
• Zerlege große Bundles mit Code Splitting; liefere nur den Code aus, den jede Seite benötigt.

<script src="/js/app.js" defer></script>
<script src="https://analytics.example.com/s.js" async></script>

Das Audit zur Gewohnheit machen

Performance ist keine einmalige Aufgabe; jedes Deployment kann ein neues Bild oder Skript einführen, das eine Regression verursacht. Füge Lighthouse deshalb deiner CI-Pipeline hinzu. Mit Lighthouse CI kannst du bei jedem Pull Request Budgets festlegen und den Build abbrechen, wenn der Score fällt. So wird „Warum ist die Seite langsamer geworden?" schon im Code-Review beantwortet, bevor sich ein Nutzer beschwert. Statt dem Score hinterherzulaufen, lauf dem Nutzer hinterher: teste auf echten Geräten unter echten Netzwerkbedingungen.

Häufig gestellte Fragen

Warum ändert sich mein Lighthouse-Score jedes Mal?

Weil die Labormessung von der aktuellen CPU-Last deines Rechners, den Netzwerkbedingungen und Hintergrundprozessen beeinflusst wird. Deshalb ist es weitaus solider, 3 bis 5 Messungen im Inkognito-Fenster vorzunehmen und den Median zu verwenden, als sich auf einen einzigen Score zu verlassen.

Muss ich unbedingt 100 erreichen?

Nein. 100 ist ein schönes Ziel, aber wirklich wichtig ist es, die Schwellenwerte der Core Web Vitals (LCP < 2,5 s, CLS < 0,1, INP < 200 ms) in den Felddaten zu bestehen. Eine Seite mit 92 und „guten" Felddaten ist besser als eine Seite mit 99 und schlechten Felddaten.

Warum unterscheiden sich Mobil- und Desktop-Scores so stark?

Lighthouse simuliert im Mobiltest ein langsames Gerät und ein gedrosseltes Netzwerk. Da die meisten deiner Nutzer mobil kommen, solltest du zuerst den Mobil-Score verbessern.

Möchtest du die Performance deiner Seite ernst nehmen? Wir können deinen Lighthouse-Bericht gemeinsam lesen und die LCP-, CLS- und TBT-Engpässe dauerhaft beheben. Kontaktiere mich und lass uns mit der Geschwindigkeitsanalyse deiner Seite beginnen.