Sofortantwort
Core Web Vitals einfach erklärt
Googles drei Kernmetriken für Ladezeit, visuelle Stabilität und Interaktivität.
- Kurz gesagt
- LCP (Largest Contentful Paint): Wie schnell lädt der größte sichtbare Inhalt? Ziel: unter 2,5 Sekunden
- Typischer Einsatz
- SEO-Ranking, Conversion-Optimierung, Performance-Monitoring
- Wichtig zu wissen
- INP (Interaction to Next Paint): Wie schnell reagiert die Seite auf Eingaben? Ziel: unter 200ms
Core Web Vitals im Überblick
Google hat drei Metriken definiert, die messen, wie gut sich eine Webseite für echte Nutzer anfühlt. Diese Core Web Vitals sind seit 2021 ein offizieller Ranking-Faktor – schlechte Werte können Rankings kosten, gute Werte sind ein Wettbewerbsvorteil.
Die drei Metriken:
| Metrik | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladezeit des größten Elements | < 2,5s | 2,5–4s | > 4s |
| CLS | Visuelle Stabilität | < 0,1 | 0,1–0,25 | > 0,25 |
| INP | Reaktionszeit auf Eingaben | < 200ms | 200–500ms | > 500ms |
Hinweis: INP hat im März 2024 FID (First Input Delay) als offiziellen Core Web Vital abgelöst. FID maß nur die erste Interaktion – INP misst alle Interaktionen während der gesamten Seitennutzung.
Weitere wichtige Metriken (nicht Core, aber relevant)
- TTFB (Time to First Byte): Wie schnell antwortet der Server? Ziel: < 800ms
- FCP (First Contentful Paint): Wann erscheint das erste Element? Ziel: < 1,8s
- TBT (Total Blocking Time): Wie lange blockiert JS den Main Thread? Ziel: < 200ms
Technisch betrachtet
LCP optimieren
Das LCP-Element ist meist ein Hero-Bild oder ein großer Textblock. Der häufigste Fehler: Das Bild wird zu spät entdeckt, weil es im CSS oder per JavaScript geladen wird.
<!-- Preload das LCP-Element (Hero-Bild) – Browser entdeckt es sofort -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
<!-- Bild mit korrekten Dimensionen – verhindert Layout Shift -->
<img
src="/hero.webp"
width="1200"
height="600"
alt="Hero"
loading="eager"
fetchpriority="high"
decoding="async"
>
LCP-Checkliste:
- Server-Response-Zeit (TTFB) unter 600ms
- Kein Render-Blocking CSS/JS vor dem LCP-Element
- Bild in WebP oder AVIF, richtig dimensioniert
- CDN nutzen für statische Assets
fetchpriority="high"für das LCP-Bild
CLS vermeiden
/* Immer Dimensionen für Bilder und Videos setzen */
img, video {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
/* Platzhalter für Ads/Embeds reservieren */
.ad-slot {
min-height: 250px;
contain: layout;
}
/* Webfonts: font-display: optional verhindert FOUT */
@font-face {
font-family: 'MyFont';
src: url('/fonts/myfont.woff2') format('woff2');
font-display: optional;
}
Häufige CLS-Ursachen:
- Bilder ohne
width/height-Attribute - Webfonts die beim Laden springen (FOUT)
- Dynamisch eingefügte Banner oder Cookie-Hinweise über bestehendem Content
- Lazy-geladene Inhalte ohne Platzhalter
INP optimieren
INP misst die Latenz von Klicks, Tastatureingaben und Taps. Hauptursache für schlechten INP: langer JavaScript-Task blockiert den Main Thread.
// Schlechter INP: Alles synchron im Click-Handler
button.addEventListener('click', () => {
const result = heavyComputation(); // Blockiert 500ms
updateUI(result);
});
// Besser: Aufteilen mit scheduler.yield()
button.addEventListener('click', async () => {
updateUI('Wird berechnet...');
await scheduler.yield(); // Main Thread freigeben
const result = heavyComputation();
updateUI(result);
});
Alle Metriken messen und reporten
import { onLCP, onCLS, onINP, onFCP, onTTFB } from 'web-vitals';
function sendToAnalytics({ name, value, rating, id }) {
// An eigenes Analytics oder Google Analytics senden
gtag('event', name, {
value: Math.round(name === 'CLS' ? value * 1000 : value),
metric_id: id,
metric_rating: rating, // 'good' | 'needs-improvement' | 'poor'
});
}
onLCP(sendToAnalytics);
onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onFCP(sendToAnalytics);
onTTFB(sendToAnalytics);
CI-Integration mit Lighthouse
# .github/workflows/lighthouse.yml
- name: Lighthouse CI
uses: treosh/lighthouse-ci-action@v10
with:
urls: |
https://www.example.com/
https://www.example.com/blog/
budgetPath: ./lighthouse-budget.json
uploadArtifacts: true
# lighthouse-budget.json
[{
"path": "/*",
"timings": [
{ "metric": "largest-contentful-paint", "budget": 2500 },
{ "metric": "cumulative-layout-shift", "budget": 100 },
{ "metric": "total-blocking-time", "budget": 200 }
]
}]
Häufige Ursachen und Lösungen
| Problem | Häufigste Ursache | Lösung |
|---|---|---|
| Schlechter LCP | Hero-Bild nicht preloaded | <link rel="preload"> + fetchpriority |
| Hoher CLS | Bilder ohne Dimensionen | width/height im HTML |
| Schlechter INP | Langer JS-Task im Click-Handler | scheduler.yield(), Web Workers |
| Schlechter TTFB | Langsamer Server / kein CDN | CDN, Edge-Caching, Server-Optimierung |
Schritt für Schritt
Web-Performance gezielt verbessern
Gute Werte entstehen nicht durch isolierte Tricks. Reale Nutzung, Engpassanalyse und ein erneuter Vergleich zeigen, welche Änderung wirklich hilft.
Nutzung messen
Messung
Felddaten und kontrollierte Tests zeigen, wo Ladezeit, visuelle Verschiebungen oder Eingaben für Menschen problematisch werden.
reale nutzung + lab test -> ausgangspunktGrößten Engpass finden
Diagnose
Das Team trennt etwa langsame Inhalte, blockierende Skripte, fehlende Platzhalter und teure Interaktionen.
metriken -> ursache im lade oder interaktionspfadGezielt verbessern
Maßnahme
Bilder, Auslieferung, Layoutreserven und JavaScript werden nur dort verändert, wo sie den gemessenen Engpass beeinflussen.
engpass -> gezielte optimierungNach Release beobachten
Nachweis
Die Wirkung wird erneut mit realen Daten geprüft, damit sich Verbesserungen nicht auf andere Geräte oder Wege negativ auswirken.
release -> felddaten -> weiter lernen
Konkretes Beispiel
Ein springendes Seitenlayout stabilisieren
Beim Laden einer Seite verschieben sich Inhalte, weil Medien und Einbettungen zu spät Platz erhalten.
Nur die Ladezeit prüfen
Die Seite wirkt schnell, aber Menschen klicken versehentlich auf verschobene Elemente oder verlieren ihre Leseposition.
Layoutstabilität gezielt messen
Reservierte Größen und stabile Ladebereiche senken die Verschiebungen. Ein erneuter Test bestätigt die Wirkung auf unterschiedlichen Geräten.
Eine schnelle Seite ist nur dann gut, wenn sie auch stabil erscheint und auf Eingaben verlässlich reagiert.
Einordnung
Vorteile und Grenzen
Das spricht dafür
- Nutzerzentrierte Sicht: Die Metriken verbinden technische Ursachen mit spürbarer Lade- und Bedienqualität.
- Klare Priorisierung: LCP, CLS und INP helfen, große Probleme im Lade- und Interaktionspfad zuerst zu adressieren.
- Regressionsschutz: Wiederholte Messungen machen sichtbar, wenn neue Releases die Erfahrung verschlechtern.
- Gemeinsame Sprache: Produkt, Design und Entwicklung können über konkrete Wirkung statt über gefühlte Geschwindigkeit sprechen.
Das solltest du beachten
- Einzelwerte erklären nicht alles: Gute Metriken ersetzen keine Prüfung von Inhalt, Aufgabenverständnis und Accessibility.
- Felddaten brauchen Zeit: Neue reale Messwerte entstehen erst, nachdem Menschen die Seite tatsächlich genutzt haben.
- Optimierung kann Zielkonflikte erzeugen: Weniger JavaScript oder Bilder darf zentrale Funktion und Verständlichkeit nicht beschädigen.
- Kontext zählt: Geräte, Netze und Nutzerwege unterscheiden sich, daher brauchen Werte eine segmentierte Einordnung.
Vertiefung · für FortgeschritteneDie drei Sichtweisen auf Seitenerlebnis
Die Kennzahlen betrachten, wann Hauptinhalt sichtbar wird, ob das Layout stabil bleibt und wie schnell Interaktionen reagieren.
Laden, Stabilität und Interaktion messen