Lighthouse-Performance-Score

Was diese Prüfung macht

Ruft die PageSpeed Insights API für die Seiten-URL auf und meldet den Gesamt-Performance-Score (0–100). Der Score ist ein gewichteter Durchschnitt aus fünf Lab-Metriken: First Contentful Paint, Largest Contentful Paint, Total Blocking Time, Cumulative Layout Shift und Speed Index.

Warum es zählt

Performance ist über Core Web Vitals ein bestätigter Ranking-Faktor und über jede je veröffentlichte Conversion-Studie ein bestätigter Conversion-Faktor. Der Lighthouse-Score ist die einfachste einzelne Zahl zum Tracken — Google selbst gruppiert ihn in drei Bänder:

90–100 (grün) — schnell. Hier hin zielen.
50–89 (orange) — verbesserungsbedürftig.
0–49 (rot) — langsam. Verliert wahrscheinlich Rankings und Conversions.

Eine Seite bei 30 ist nicht ein bisschen schlechter als eine bei 80; sie verliert Besucher, bevor sie irgendwas sehen.

So behebst du es

Performance-Arbeit ist eine geschichtete Anstrengung. Die größten Hebel zuerst:

1. Größte Bilder optimieren (LCP).

Die meisten langsamen Seiten sind langsam wegen eines Hero-Bildes von 2–5 MB. Komprimiere es, liefere AVIF/WebP aus, setze explizite width und height:

<img
  src="/hero.avif"
  width="1200"
  height="630"
  alt="…"
  fetchpriority="high"
  loading="eager">

fetchpriority="high" sagt dem Browser, dieses Bild vor unkritischen Assets zu laden — verbessert LCP direkt.

2. Unkritisches JavaScript verzögern (TBT und INP).

Jedes Analytics-, Chat-Widget- und A/B-Test-Skript läuft auf dem Main-Thread, bevor Nutzer:innen interagieren können. Defer oder async:

<script src="/analytics.js" defer></script>
<script src="https://plausible.io/js/plausible.js" defer></script>

Für React/Next.js: schwere Komponenten code-splitten, dynamic(() => import(...), { ssr: false }) für Widgets unter dem Fold nutzen und Drittanbieter-Skripte in DevTools’ Performance-Tab auditieren.

3. Kritisches CSS inline, Rest verzögern.

<style>/* kritisches CSS — sichtbar oberhalb des Folds */</style>
<link rel="preload" href="/main.css" as="style" onload="this.rel='stylesheet'">

Critical-CSS-Extraktoren (Critters, Beasties für Next.js, astro:assets für Astro) automatisieren das.

4. Platz für dynamische Inhalte reservieren (CLS).

Jedes Bild braucht width und height. Jedes Embed einen expliziten Container. Jeder Webfont braucht font-display: swap und einen Fallback mit passenden Metriken.

5. Cachen, komprimieren, CDN.

Statische Assets per CDN (Cloudflare, Bunny, Fastly) ausliefern. Brotli-Kompression für HTML/CSS/JS aktivieren. Cache-Control: public, max-age=31536000, immutable auf fingerprinted Assets setzen.

Tools dafür:

PageSpeed Insights — dieselbe Engine, die MetricSpot aufruft. Zeigt spezifische Audit-Failures.
Chrome DevTools → Performance-Panel — finde das tatsächlich langsame Frame.
npx unlighthouse https://yourdomain.com — Lighthouse gegen jede Seite, nicht nur die Startseite.
WebPageTest — für Tests aus bestimmten Geografien und Verbindungstypen.

Verwandte Prüfungen: LCP, INP, CLS.

Häufig gestellte Fragen

Warum unterscheidet sich mein lokaler Lighthouse-Score von PSI?

Lokales Lighthouse nutzt deine CPU und dein Netz; PSI nutzt ein gedrosseltes Midrange-Android-Gerät auf einer 4G-Verbindung. PSI ist, was Google fürs echte Signal verwendet — stimme immer dagegen ab, nicht gegen den Score deines M3-MacBooks.

Beeinflusst der Score das Ranking direkt?

Indirekt. Google rankt nach den drei Core Web Vitals (LCP, INP, CLS) — nicht nach dem Composite-Score. Aber ein niedriger Lighthouse-Score bedeutet fast immer, dass die zugrundeliegenden CWV-Metriken ebenfalls schlecht sind. Repariere die Metriken; der Score folgt.

Mein Score schwankt zwischen Besuchen — warum?

Felddaten (was PSI zeigt, wenn die URL genug Chrome-Nutzer-Traffic hat) sind stabil. Lab-Daten (ein einzelner Lighthouse-Lauf) sind variabel — Server warm/kalt, Werbenetzwerke laden andere Creatives, Drittanbieter-Skripte. Lass PSI dreimal laufen und nimm den Median, oder verlasse dich auf die 28-Tage-Felddaten, wenn verfügbar.