11. Januar 2026
4 Min. Lesezeit
SEOPerformanceWebentwicklung

Core Web Vitals verständlich erklärt: LCP, INP, CLS (und was du wirklich tun musst)

Core Web Vitals klingen technisch – sind aber simpel: Ladezeit, Reaktionszeit und Layout-Stabilität. So verbesserst du sie praktisch.

Geschwindigkeit und Performance Symbolik
Gute Performance hilft SEO – und vor allem echten Nutzern.

Google misst nicht „schönes Design“, sondern Nutzererlebnis. Core Web Vitals sind dafür ein praxisnaher Proxy.

In diesem Guide bekommst du:

  • klare Zielwerte (was „gut“ bedeutet)
  • wie du richtig misst (Felddaten vs. Lab)
  • die häufigsten Ursachen pro Metrik
  • konkrete Quick-Fixes, die in der Praxis am meisten bringen

Kurzüberblick: Zielwerte

Als grobe Orientierung (Google „good“):

| Metrik | „Gut“ | „Verbesserungswürdig“ | | --- | --- | --- | | LCP | < 2,5s | 2,5–4,0s | | INP | < 200ms | 200–500ms | | CLS | < 0,1 | 0,1–0,25 |

Wichtig: Entscheidend sind Felddaten (echte Nutzer). Eine Seite kann in Lighthouse gut aussehen und im Feld trotzdem Probleme haben (z.B. durch reale Geräte, echte Netzwerke, Third-Party-Skripte).

Richtig messen (ohne dich zu verrennen)

Es gibt zwei Datenarten:

  • Felddaten (Real User Monitoring / CrUX): echte Nutzer, echte Geräte → relevant für Google.
  • Lab-Daten (Lighthouse/DevTools): Simulation → ideal zum Debuggen.

Tools, die sich bewährt haben:

  • Google Search Console: Core Web Vitals Bericht (Gruppierung nach URL-Mustern)
  • PageSpeed Insights: Lab + Felddaten (CrUX), gute Hinweise
  • Chrome DevTools: Performance-Panel, Coverage, Network-Wasserfall

Wenn du Next.js nutzt, sind außerdem hilfreich:

  • Bundle-Analyse / Skript-Gewicht (was lädt überhaupt?)
  • Monitoring in der Realität (z.B. über Web-Vitals-Messung im Frontend)

Die drei wichtigsten Werte (mit Praxis-Fixes)

LCP (Largest Contentful Paint)

Worum geht’s? Wie schnell der wichtigste Inhalt sichtbar ist.

Typisch ist das: Hero-Bild, großer Heading-Block oder ein Above-the-fold-Element.

Typische Ursachen:

  • zu große/ungünstig geladene Bilder (Hero)
  • hoher TTFB (Server antwortet langsam)
  • Render-Blocking durch CSS/JS
  • zu viel Above-the-fold (Slider, Videos, große Animationen)

Quick-Fixes (die meistens sofort helfen):

  • Hero-Bild richtig ausliefern (Größe, Format, Priorisierung). In Next.js: next/image, sinnvolle sizes, und nur dort priority, wo es wirklich Above-the-fold ist.
  • TTFB senken: Caching/CDN, Server-Performance, unnötige Datenabfragen vermeiden. (Siehe auch: Caching/CDN & TTFB).
  • Render-Blocking reduzieren: kritische Styles früh, Rest nachladen; unnötige CSS/JS entfernen.
  • Third-Party entschärfen: Chat, Maps, Tracking erst nach Consent und ggf. erst nach Interaktion laden.

Wenn du tiefer rein willst: LCP-Bilder in Next.js richtig optimieren.

INP (Interaction to Next Paint)

Worum geht’s? Wie schnell die Seite auf Interaktionen reagiert (Klick, Tippen).

Typische Ursachen:

  • zu viel JavaScript (Download + Parsing + Ausführung)
  • „lange Tasks“ im Main Thread (z.B. riesige Bundles)
  • Third-Party-Skripte (Tag Manager, Widgets, Heatmaps)
  • teure React-Renders (zu große Komponentenbäume, unnötige Re-renders)

Quick-Fixes:

  • JS reduzieren: Features/Libs entfernen oder ersetzen; nur laden, was wirklich gebraucht wird.
  • Code splitten: dynamische Imports für selten genutzte Komponenten (z.B. Slider, Karten).
  • Third-Party lazy laden: erst nach Consent und möglichst nach Interaktion.
  • Renders stabilisieren: schwere Komponenten memoizen, Props stabil halten, unnötige State-Updates vermeiden.

Debug-Ansatz:

  • Chrome DevTools → Performance: nach „Long tasks“ schauen.
  • Network → große JS-Dateien identifizieren.

CLS (Cumulative Layout Shift)

Worum geht’s? Springt das Layout beim Laden?

Typische Ursachen:

  • Bilder/Medien ohne fest reservierten Platz (Width/Height oder Aspect Ratio)
  • Fonts ohne sauberes Loading (Layout-Switch durch spätes Font-Laden)
  • Widgets/Embeds, die nachträglich Inhalt einfügen (Consent, Chat, iFrames)

Quick-Fixes:

  • Platz reservieren: für Bilder/Videos/iFrames feste Dimensionen oder aspect-ratio.
  • Fonts stabil laden: font-display: swap und möglichst nur notwendige Schriftschnitte.
  • Consent/Widgets: Container mit fixer Höhe reservieren oder erst nach User-Interaktion einblenden.

Wenn du CLS-Probleme hast, ist das oft „ein paar kleine Details“ – aber die Details sind entscheidend.

Priorisierung: Was bringt am meisten?

Wenn du nur begrenzte Zeit hast, ist das hier oft das beste 80/20:

  1. Hero/LCP fixen (Bild + Above-the-fold + TTFB)
  2. Third-Party reduzieren (besonders auf Mobile)
  3. CLS eliminieren (Platz reservieren, Fonts)
  4. JS-Gewicht senken (INP wird meistens automatisch besser)

10 Maßnahmen, die fast immer helfen

  1. Bilder korrekt dimensionieren und komprimieren.
  2. Hero-Elemente priorisieren (aber nicht „alles“ als priority).
  3. Fonts sauber laden (kein Layout-Springen, nur nötige Schnitte).
  4. Third-Party-Skripte radikal prüfen (brauchen wir das wirklich?).
  5. Tracking/Consent so bauen, dass es nicht blockiert oder springt.
  6. JS-Bundles verkleinern (unnötige Dependencies raus).
  7. Code splitting / lazy loading für selten genutzte UI.
  8. Caching/CDN nutzen (TTFB ist häufig der versteckte Bremsklotz).
  9. Mobile Performance als Standard nehmen (nicht als „später“).
  10. Nach dem Fix erneut messen: Lab und Felddaten beobachten.

Next.js Quick Wins (typisch bei App Router/React)

  • Nutze next/image konsequent und gib sinnvolle sizes an.
  • Vermeide große Client Components „nur weil’s einfacher ist“: je mehr im Client, desto mehr JS.
  • Third-Party nur dort einbauen, wo es wirklich gebraucht wird (z.B. Maps nicht auf jeder Seite).

Wenn du dich tiefer mit Next.js & SEO/Performance beschäftigen willst: Next.js SEO im App Router.

Was du davon als Business mitnehmen solltest

Wenn deine Seite schneller und stabiler wird, steigen meist:

  • Verweildauer,
  • Conversion (Anfragen/Käufe),
  • organische Sichtbarkeit.

Praktisch heißt das: Core Web Vitals sind nicht „nur SEO“. Sie sind ein Conversion-Hebel – besonders auf Mobile.

Mini-Checkliste vor dem nächsten Release

  • LCP: Hero-Bild optimiert + TTFB ok?
  • INP: Keine langen Tasks, kein unnötiges JS/Third-Party?
  • CLS: Reservierter Platz für Medien/Widgets, Fonts stabil?
  • Tracking: Consent sauber, Events geprüft?
  • Mobile: einmal real auf einem normalen Handy testen (nicht nur Desktop-Lighthouse)

Nächster Schritt

Wenn du möchtest, machen wir einen Performance-Check und priorisieren die Maßnahmen nach Aufwand/Impact.

Weiterlesen

Passend dazu

FAQ

Welche Core Web Vitals sind am wichtigsten?
Die drei Kernwerte sind LCP (Ladezeit des Hauptinhalts), INP (Reaktionszeit) und CLS (Layout-Stabilität).
Welche Werte gelten als gut?
Als grobe Orientierung: LCP unter 2,5s, INP unter 200ms und CLS unter 0,1.
Woran sehe ich die echten Werte von Nutzern?
Am verlässlichsten über Felddaten: Google Search Console (Core Web Vitals Bericht) und PageSpeed Insights (CrUX). Lighthouse ist eher Lab/Simulation.
Was verschlechtert INP am häufigsten?
Zu viel oder schweres JavaScript (lange Tasks), große Third-Party-Skripte und komplexe Animationen.
Wie verbessere ich LCP am schnellsten?
Hero-Bild optimieren (Größe/Format), Render-Blocking reduzieren und Above-the-fold priorisieren (kritisches CSS, weniger JS).
Wie schnell wirken Änderungen auf die Core Web Vitals?
Lab-Tools zeigen Effekte sofort, Felddaten brauchen länger. In der Search Console siehst du Trends oft erst nach einigen Tagen/Wochen (je nach Traffic).
Bringen bessere Web Vitals wirklich SEO?
Sie sind ein Ranking-Signal und verbessern vor allem die Nutzererfahrung – was indirekt Conversion und Engagement steigert.