Performance 6 min Lesezeit

Core Web Vitals 2025: Was wirklich zählt

Google hat die Core Web Vitals wieder angepasst. Was bedeutet das für dein Ranking? Ich zeige dir, welche Metriken jetzt entscheidend sind und wie du sie mit modernen Tools in den Griff bekommst.

core-web-vitals.webp

LCP, INP und CLS im Detail

Google bewertet Webseiten zunehmend nach Nutzererfahrung – Core Web Vitals sind dabei der zentrale Maßstab fürs Ranking. Die drei Metriken:

  • LCP (Largest Contentful Paint): Wie schnell lädt das größte sichtbare Element?
  • INP (Interaction to Next Paint): Wie reaktionsschnell ist die Seite auf Eingaben?
  • CLS (Cumulative Layout Shift): Wie stabil ist das Layout beim Laden?

Was hat sich 2024/2025 geändert?

Seit März 2024 hat Google FID (First Input Delay) offiziell durch INP ersetzt. Das ist ein größerer Schritt als es klingt: FID maß nur die Latenz des allerersten Klicks. INP hingegen bewertet jede Interaktion – jeden Klick, jede Texteingabe, jeden Hover-Effekt während der gesamten Sitzung. Das macht INP zu einer deutlich strengeren und realistischeren Metrik für die tatsächliche Nutzererfahrung.

Ein INP unter 200ms gilt als "gut", 200–500ms als "verbesserungswürdig", darüber als "schlecht".

LCP: Das größte sichtbare Element schnell laden

LCP misst, wie lang es dauert, bis das größte sichtbare Element im Viewport geladen ist – meist ein Hero-Bild, ein H1-Text oder ein Video-Poster. Ziel: unter 2,5 Sekunden.

Typische Ursachen für schlechten LCP:

  • Bilder ohne fetchpriority="high" auf dem Hero-Element
  • Schriften blockieren das Rendering (font-display: block)
  • Langsame Server-Antwortzeiten (TTFB über 600ms)
  • Kein CDN für statische Assets

Lösung: Das LCP-Element explizit mit <link rel="preload" as="image"> oder fetchpriority="high" priorisieren. Bei Webfonts font-display: swap oder optional nutzen.

INP: Interaktionen flüssig halten

INP-Probleme entstehen fast immer durch zu viel JavaScript im Main Thread. Long Tasks (über 50ms) blockieren den Browser und verzögern die Reaktion auf Nutzereingaben.

Praktische Maßnahmen:

  • JavaScript-Bundles aufteilen und nur laden, was wirklich gebraucht wird
  • Schwere Berechnungen mit requestIdleCallback oder Web Workers auslagern
  • Event-Handler optimieren, keine synchronen XHR-Calls
  • Third-Party-Scripts (Chat-Widgets, Analytics) asynchron und verzögert laden

CLS: Layout-Sprünge vermeiden

Nichts nervt Nutzer mehr als eine Seite, die sich beim Laden verschiebt. CLS entsteht oft durch Bilder ohne definierte width/height, dynamisch injizierte Ads oder Schriften die die Textgröße nachträglich ändern.

Checkliste gegen CLS:

  • Alle Bilder und Videos mit width und height im HTML
  • Platzhalter für asynchron geladene Inhalte (Skeleton Screens)
  • Schriften mit font-display: optional laden oder in den Build-Prozess einbinden
  • Sticky-Elemente und Banner oben auf der Seite vermeiden oder reservierten Platz nutzen

Tools zur Messung

  • PageSpeed Insights: Zeigt Feld- und Labordaten direkt für deine URL
  • Chrome DevTools → Performance: Detaillierte Aufzeichnung von INP und Long Tasks
  • Lighthouse: CI-Integration möglich, z.B. via lighthouse-ci in GitHub Actions
  • Web Vitals Extension: Echtzeit-Anzeige im Browser während des Surfens

Fazit

Core Web Vitals sind kein einmaliges Projekt, sondern ein kontinuierlicher Prozess. Jedes neue Feature, jedes Plugin, jede Third-Party-Integration kann die Werte verschlechtern. Wer regelmäßig misst und iterativ optimiert, hält seinen Lighthouse-Score dauerhaft über 90 – und damit auch sein Google-Ranking stabil.

Zurück zum Blog

Weitere Beiträge

WhatsApp