< Zurück zu Insights

Performance

Core Web Vitals: Was wirklich zählt (LCP/INP/CLS)

Performance ist kein Lighthouse-Spiel. Entscheidend ist, ob Nutzer schnell den Hauptinhalt sehen (LCP), Interaktionen sofort reagieren (INP) und das Layout stabil bleibt (CLS). Core Web Vitals sind dafür gemacht, reale Nutzererfahrung messbar zu machen - nicht Tool-Scores zu gamen.

10.02.2026 · 16 Min

1) Core Web Vitals in 30 Sekunden

Core Web Vitals sind drei Metriken für Loading, Interactivity und Visual Stability: LCP, INP und CLS.

Wichtig: Google nutzt sie als Teil von Page Experience, aber gute Werte allein garantieren keine Top-Rankings. Sie helfen vor allem, wenn Inhalte und Relevanz ähnlich stark sind.

  • LCP = Wann sieht man den Hauptinhalt wirklich?
  • INP = Wie schnell fühlt sich jede Interaktion an?
  • CLS = Springt die Seite beim Laden sichtbar?

2) Was gut wirklich heißt: Grenzwerte plus 75-Perzentil (das übersehen viele)

Core Web Vitals bewertest du nicht am Durchschnitt, sondern typischerweise am 75. Perzentil. Das heißt: 75 Prozent der Seitenaufrufe sollen im Good-Bereich liegen.

Eine Seite oder Origin gilt als bestanden, wenn alle drei Metriken am 75. Perzentil im Good-Bereich liegen.

  • LCP Good: <= 2,5s (Needs improvement: 2,5-4,0s, Poor: > 4,0s)
  • INP Good: <= 200ms (Needs improvement: 200-500ms, Poor: > 500ms)
  • CLS Good: <= 0,1 (Needs improvement: 0,1-0,25, Poor: > 0,25)

3) Field vs Lab: Welche Daten zählen wirklich?

Field Data sind echte Nutzerdaten auf echten Geräten und Netzwerken. Genau diese Realität ist für die Bewertung entscheidend.

Lab Data aus Lighthouse bleibt wichtig, aber primär für Diagnose und Reproduktion von Ursachen. Dass Lab und Field auseinanderlaufen, ist normal.

  • Lab ist Diagnostik: Wo liegt der Engpass?
  • Field ist Realität: Was erleben Nutzer wirklich?
  • Profi-Move: zusätzlich 90. und 95. Perzentil beobachten, um Worst Cases zu sehen

4) So liest du den Core Web Vitals Report in der Search Console

Die Search Console gruppiert URLs und bewertet Good, Needs improvement oder Poor auf Basis echter Nutzerdaten.

Entscheidend: Eine URL-Gruppe wird vom schlechtesten Vital bestimmt. Ein schlechter CLS kann also die Gruppe auf Poor ziehen, auch wenn LCP und INP gut sind.

  • Nicht jede URL ist einzeln messbar, häufig gibt es URL-Gruppen
  • Nicht genug Daten heißt nicht alles okay, sondern noch nicht belastbar messbar
  • Priorisiere zuerst die größten Gruppen mit echtem Business-Impact

5) INP statt FID: Was sich geändert hat und warum das wichtig ist

INP hat FID als Core Web Vital abgelöst, weil INP die Responsiveness über die ganze Session abbildet statt nur den ersten Input.

Damit wird Performance näher an der Nutzerrealität gemessen: Eine Seite kann beim ersten Klick schnell sein und später trotzdem träge wirken.

  • Ziel ist durchgängig schnelle Interaktion, nicht nur ein guter First Input
  • INP-Probleme sind meist Main-Thread-Probleme (JS, Rendering, Third-Party)

6) LCP: Wann sieht man den Hauptinhalt? (und warum es oft nicht am letzten Prozent liegt)

LCP misst den Render-Zeitpunkt des größten sichtbaren Elements im Viewport, oft ein Hero-Bild oder ein großer Textblock.

In Field-Daten kann LCP deutlich schlechter ausfallen als im Lab, weil dort Connection-Setup, Redirects und TTFB-Anteile mit reinspielen.

  • Häufige Ursachen: hoher TTFB, zu große Hero-Assets, Render-Blocking, schwere Third-Party-Skripte
  • Diagnose: LCP-Element identifizieren, dann TTFB, Resource Load und Render Delay getrennt prüfen
  • Fixes: Hero optimieren, Critical Path entschlacken, Fonts und Third-Party bewusst priorisieren

7) INP: Jeder Klick muss sofort reagieren (Main-Thread-Realität)

INP misst die Latenz bis zum nächsten Paint nach Interaktionen. Das hängt direkt an Main-Thread-Auslastung, Event-Handlern und Render-Kosten.

Gerade auf interaktiven Seiten entstehen schlechte INP-Werte durch lange Tasks, große Client-Bundles und zu viel Hydration.

  • Typische Ursachen: Long Tasks, teure Handler, Re-Render-Kaskaden, blockierende Third-Party-Skripte
  • Diagnose: träge Interaktionen identifizieren und im Profiling rund um diese Aktionen analysieren
  • Fix-Pattern: JS reduzieren, Long Tasks aufteilen, Workflows entkoppeln, Third-Party später laden

8) CLS: Nichts darf springen (weil Vertrauen in Sekunden verloren geht)

CLS misst Layout-Verschiebungen im sichtbaren Bereich. Für Nutzer fühlt sich das an wie fehlende Kontrolle beim Lesen oder Klicken.

Die häufigsten Ursachen sind fehlende Platzhalter für Medien/Embeds, spät injizierte Elemente und unklare Font-Strategien.

  • Häufige Ursachen: Bilder ohne Dimensionen, Embeds ohne reservierten Platz, dynamische Banner, Font-Swaps
  • Diagnose: Shift-Hotspots im Viewport identifizieren und betroffene Komponenten isolieren
  • Fixes: feste Containergrößen, reservierte Slots, geplante UI-Zustände und robuste Font-Ladestrategie

9) Priorisierung: Welche Seiten zuerst?

Core Web Vitals sollten nach Business-Impact priorisiert werden: zuerst SEO-Landingpages und Seiten im Conversion-Pfad.

Der stärkste Hebel liegt oft im Template-Fix statt im Einzelseiten-Tuning.

  • Tier 1: Top-Landingpages plus Money-Pages
  • Tier 2: skalierende Templates wie Insights/Blog
  • Tier 3: Restseiten nur bei geringem Aufwand

10) Ein Performance-Sprint, der wirklich Ergebnisse liefert (2 Wochen)

Core Web Vitals nebenbei zu verbessern scheitert fast immer. Ein Sprint mit klaren Deliverables schafft Fokus und messbaren Fortschritt.

  • Woche 1: Field-Baseline, Top-Templates, LCP-Elemente, Third-Party-Audit, CLS-Hotspots
  • Woche 2: LCP-, INP- und CLS-Fixes umsetzen plus Regression-Gates definieren
  • Abnahme: Core-Templates dürfen gegenüber Baseline nicht schlechter werden

11) Monitoring: Wie du verhinderst, dass es wieder schlechter wird

Ohne Monitoring sind Core-Web-Vitals-Verbesserungen oft nach wenigen Wochen wieder weg, etwa durch neue Skripte oder ungeplante Assets.

Gute Praxis ist ein Release-Gate pro Core-Template plus regelmäßiger Blick auf GSC-Gruppen und Feldsignale.

  • Release-Gate: keine CWV-Regression auf Kernseiten
  • Monatlicher Review: Poor-Buckets, betroffene URL-Gruppen, neue Third-Party-Last
  • Wenn möglich eigenes RUM ergänzen, da Field-Realität entscheidend ist

12) Copy-Paste Checkliste: Wenn du nur diese Punkte machst

Diese Minimal-Liste bringt in vielen Projekten schnell spürbare Verbesserung, ohne Lighthouse-Show oder Micro-Optimierungs-Theater.

  • Grenzwerte und 75-Perzentil korrekt interpretieren
  • Field und Lab sauber trennen
  • Templates statt Einzelseiten priorisieren
  • LCP-Elemente pro Template identifizieren und Critical Path entschlacken
  • INP-Blocker am Main Thread systematisch abbauen
  • CLS mit festen Dimensionen und Slots stabilisieren
  • Monitoring plus Release-Gates verbindlich einführen

FAQ: Warum habe ich in Lighthouse gute Werte, aber in der Realität schlechte?

Lighthouse misst im Lab unter kontrollierten Bedingungen. Field-Daten enthalten reale Netzwerke, Geräte und Servereffekte und sind deshalb oft härter.

Gerade LCP kann im Feld deutlich schlechter sein, wenn TTFB, Redirects oder Mobile-Geräte limitieren.

FAQ: Zählt Core Web Vitals wirklich für SEO?

Ja, Core Web Vitals fließen in Page Experience ein. Gleichzeitig gilt: Gute CWV allein garantieren keine Top-Position, wenn Inhalt und Intent nicht passen.

FAQ: Warum zeigt die Search Console nicht genug Daten?

Der CWV-Report basiert auf realen Nutzerdaten und arbeitet oft mit URL-Gruppen. Bei geringem Volumen kann eine Gruppe noch nicht stabil klassifiziert werden.

FAQ: Was ist der schnellste Hebel für bessere LCP-Werte?

In vielen Projekten sind TTFB/Caching plus Priorisierung des LCP-Elements die schnellsten Hebel. Danach folgen Render-Blocking und Third-Party-Last.

FAQ: Was ist der häufigste Grund für schlechte INP?

Main-Thread-Blockade durch lange JS-Tasks, teure Event-Handler oder zu viel Client-Rendering. INP reagiert sehr sensibel auf diese Faktoren.

FAQ: Was verursacht CLS am häufigsten?

Typisch sind Bilder und Embeds ohne reservierten Platz sowie Font- und UI-Zustände, die Inhalte nachträglich verschieben.

Abschluss: So wird aus Performance-Stress ein kontrollierbarer Prozess

Core Web Vitals werden beherrschbar, wenn du sie als System behandelst: Field-Daten messen, nach Impact priorisieren, pro Template fixen und Regression verhindern.

Genau so zahlt sich Performance messbar in UX, Conversion und langfristig auch in SEO aus.

Quellen

Mehr Insights

Passende Leistungen

Autor

Michael Reimer

Fachinformatiker und Entwickler hinter Reimcode

Michael Reimer entwickelt mit Reimcode Websites, Web-Apps und technische Setups mit Fokus auf saubere Umsetzung, klare Struktur und belastbare Entscheidungen.

Mehr über mich

Nächster Schritt

Core Web Vitals bleiben instabil?

Wir priorisieren die echten Bottlenecks anhand von Field-Daten und Template-Impact und setzen daraus einen umsetzbaren Performance-Sprint auf - ohne Lighthouse-Show, mit messbaren Ergebnissen.