12 Min. Lesezeit

Core Web Vitals: LCP, INP und CLS einfach erklärt

Technical SEOWebsite-OptimierungPerformance
Titelbild für "Core Web Vitals: LCP, INP und CLS einfach erklärt"

Der Tag, an dem Google meine Rankings zerstörte (und wie ich sie zurückholte)

Es war Juni 2021. Ich wachte auf, checkte routinemäßig meine Rankings – und mein Herz blieb stehen.

Meine Top-3-Rankings? Weg. Position 8, 12, 15. Mein Traffic war über Nacht um 40% eingebrochen. Ich hatte keine technischen Änderungen gemacht, keine Penalties, nichts. Was zur Hölle war passiert?

Dann sah ich es: Google Core Web Vitals Update. Eingeführt im Mai 2021, voll ausgerollt im Juni. Und meine Website? Fiel bei allen drei Metriken gnadenlos durch.

Die nächsten 3 Wochen waren Hölle. Ich lernte mehr über Ladezeiten, JavaScript-Optimierung und Layout-Shifts, als mir lieb war. Aber am Ende hatte ich es geschafft: Alle drei Core Web Vitals im grünen Bereich. Und meine Rankings? Innerhalb von 4 Wochen komplett zurück.

Heute, fast 4 Jahre später, sind Core Web Vitals ein offizieller Ranking-Faktor. Wenn Sie sie ignorieren, ignorieren Sie messbare Rankings und Traffic. Lassen Sie mich Ihnen zeigen, was sie bedeuten – ohne den technischen Overkill.

Was sind Core Web Vitals? Die Basics

Core Web Vitals sind drei spezifische Metriken, die Google nutzt, um die User Experience Ihrer Website zu messen. Nicht Ihre Meinung über UX. Nicht Designer-Geschmack. Harte, messbare Zahlen.

Google hat gesagt: “Diese drei Dinge sind uns wichtig für eine gute Nutzererfahrung. Wenn eure Website hier versagt, werden wir das beim Ranking berücksichtigen.”

Die drei Metriken:

  1. LCP (Largest Contentful Paint) – Ladegeschwindigkeit
  2. INP (Interaction to Next Paint) – Interaktivität (ersetzt FID seit März 2024)
  3. CLS (Cumulative Layout Shift) – Visuelle Stabilität

Jede misst einen anderen Aspekt der Nutzererfahrung. Zusammen geben sie ein ziemlich gutes Bild davon, wie “smooth” Ihre Website für echte Nutzer ist.

Wichtig: Core Web Vitals sind kein On/Off-Ranking-Faktor. Es ist nicht: “Bestanden = Page 1, Durchgefallen = Page 10”. Aber es ist ein Tiebreaker. Bei ansonsten gleicher Relevanz und Autorität gewinnt die schnellere, stabilere Website.

Und in kompetitiven Nischen? Da kann das den Unterschied zwischen Position 3 und Position 8 ausmachen. Und das ist der Unterschied zwischen profitabel und unsichtbar.

Core Web Vital #1: LCP (Largest Contentful Paint)

Was misst LCP?

LCP misst, wie lange es dauert, bis der größte sichtbare Inhalt im Viewport (sichtbarer Bereich ohne Scrollen) geladen ist.

Nicht die ganze Seite. Nicht jedes Detail. Sondern: “Wann sieht der Nutzer den Hauptinhalt?”

Was zählt als “largest content”?

  • Hero-Images
  • Header-Bilder
  • Große Textblöcke (z.B. Artikelüberschrift + erster Absatz)
  • Große Video-Thumbnails

Was zählt NICHT?

  • Bilder, die erst nach dem Scrollen sichtbar werden
  • Kleine Icons und Logos
  • Hintergrundbilder (meist)

Die Grenzwerte: Gut, OK, Schlecht

Google definiert drei Bereiche:

  • Gut (Grün): ≤ 2,5 Sekunden
  • Verbesserungsbedürftig (Orange): 2,5 - 4,0 Sekunden
  • Schlecht (Rot): > 4,0 Sekunden

Brutal ehrlich: Unter 2,5 Sekunden ist 2025 das Minimum. Ich ziele bei meinen Projekten auf unter 2,0 Sekunden ab, idealerweise 1,5s.

Warum ist LCP wichtig? Die harten Zahlen

Ich könnte Ihnen jetzt Google-PR erzählen. Stattdessen harte Daten aus meinen eigenen Projekten:

Kundenwebsite (E-Commerce): LCP von 4,8s auf 1,9s reduziert

  • Absprungrate: -23%
  • Conversion Rate: +31%
  • Durchschnittliche Session-Dauer: +42%

Ja, ein langsameres Laden kostet Sie direkt Geld. Jede Sekunde zählt.

Häufigste LCP-Probleme (und Lösungen)

Problem 1: Riesige, unkomprimierte Bilder

Das sehe ich in 80% aller Fälle. Hero-Image mit 5 MB, direkt vom Fotografen hochgeladen.

Lösung:

  • Bilder komprimieren (TinyPNG, ImageOptim, Squoosh)
  • Moderne Formate nutzen (WebP statt JPG/PNG)
  • Responsive Images (srcset) für verschiedene Bildschirmgrößen
  • Mein Tipp: Hero-Images nie über 200 KB, besser unter 100 KB

Problem 2: Render-blocking CSS und JavaScript

Ihr Browser muss erst alle CSS- und JS-Dateien laden, bevor er mit dem Rendern beginnt.

Lösung:

  • Kritisches CSS inline im <head> einfügen
  • Nicht-kritisches CSS asynchron laden
  • JavaScript mit defer oder async laden
  • Mein Tipp: Nutzen Sie Tools wie Critical CSS Generator

Problem 3: Langsame Server-Antwortzeiten

Wenn Ihr Server 2 Sekunden braucht, um überhaupt zu antworten, haben Sie LCP schon halb verloren.

Lösung:

  • Besseres Hosting (Shared Hosting ist 2025 ein No-Go für ernsthafte Websites)
  • CDN nutzen (Cloudflare, KeyCDN)
  • Caching aktivieren
  • Mein Tipp: Server Response Time (TTFB) sollte unter 200ms liegen

Problem 4: Web Fonts, die ewig brauchen

Custom Fonts von Google Fonts oder Adobe sind schön, aber oft langsam.

Lösung:

  • Fonts lokal hosten (nicht von externen Servern laden)
  • font-display: swap nutzen
  • Nur die wirklich benötigten Font-Weights laden (nicht Regular + Medium + Bold + Black)
  • Mein Tipp: Überlegen Sie, ob Sie wirklich 4 verschiedene Fonts brauchen

Mein LCP-Worst-Case-Szenario

Ein Kunde kam zu mir: Online-Magazin, schönes Design, aber LCP bei 7,2 Sekunden. Sieben. Punkt. Zwei.

Was wir fanden:

  • Hero-Image: 8,4 MB (!!!)
  • 3 externe Schriftarten, 12 verschiedene Weights
  • JavaScript-Slideshow, die 4 Bibliotheken lädt
  • Server in den USA (Kunde sitzt in Österreich)
  • Kein Caching

Was wir gemacht haben:

  1. Hero-Image auf 85 KB komprimiert (WebP, optimiert)
  2. Fonts auf 2 Familien reduziert, lokal gehostet
  3. Slideshow gegen einfaches statisches Bild getauscht (A/B-Test zeigte: Slideshow hatte ohnehin 0 Interaktionen)
  4. Server nach Frankfurt verlegt + CDN aktiviert
  5. Caching aggressiv konfiguriert

Ergebnis: LCP 1,6 Sekunden. Von 7,2s auf 1,6s. Traffic +65% innerhalb von 8 Wochen.

Core Web Vital #2: INP (Interaction to Next Paint)

Was misst INP?

INP misst die Reaktionsfähigkeit Ihrer Website auf Nutzerinteraktionen. Wenn jemand auf einen Button klickt, wie schnell reagiert die Seite?

Wichtig: INP hat im März 2024 die alte Metrik FID (First Input Delay) ersetzt. FID maß nur die erste Interaktion, INP misst alle Interaktionen während des gesamten Seitenbesuchs.

Was zählt als Interaktion?

  • Klicks auf Buttons, Links
  • Tap auf Touch-Geräten
  • Tastatureingaben

Die Grenzwerte

  • Gut (Grün): ≤ 200 Millisekunden
  • Verbesserungsbedürftig (Orange): 200 - 500 ms
  • Schlecht (Rot): > 500 ms

Kontext: 200ms ist verdammt schnell. Alles über 100ms fühlt sich für Nutzer schon leicht träge an. Über 500ms und sie denken, Ihre Seite ist kaputt.

Warum ist INP wichtig?

Stellen Sie sich vor: Sie sind auf einem Online-Shop, legen ein Produkt in den Warenkorb. Sie klicken auf “In den Warenkorb”. Und… nichts. Eine Sekunde. Zwei Sekunden. War der Klick registriert? Klicken Sie nochmal? Laden Sie die Seite neu?

Dieser Frustrations-Moment kostet unzählige Conversions.

Real-World-Beispiel:

Ein Kunde (SaaS-Plattform) hatte ein INP-Problem bei der Registrierung. Nutzer klickten auf “Registrieren”, aber wegen JavaScript-Overhead dauerte die Reaktion 800ms.

Das klingt nach nichts. Aber: 12% der Nutzer klickten zweimal (dachten, der erste Klick hat nicht funktioniert) → Duplikate, Fehler, Frustration.

Wir reduzierten INP auf 150ms. Doppelklick-Rate fiel auf 2%. Erfolgreiche Registrierungen stiegen um 18%.

Häufigste INP-Probleme

Problem 1: JavaScript-Overload

Zu viel JavaScript, das beim Klick ausgeführt werden muss.

Lösung:

  • JavaScript-Bundles aufteilen (Code Splitting)
  • Nicht verwendetes JavaScript entfernen
  • Heavy Processing in Web Workers auslagern
  • Mein Tipp: Chrome DevTools → Performance-Tab nutzen, um lange Tasks zu identifizieren

Problem 2: Zu viele Third-Party-Scripts

Google Analytics, Facebook Pixel, Hotjar, Chatbots, Newsletter-Tools… jedes Script kann INP verschlechtern.

Lösung:

  • Scripts asynchron laden
  • Nicht essenzielle Scripts per Consent erst nach Nutzerinteraktion laden
  • Regelmäßig ausmisten: Brauchen Sie wirklich 7 Tracking-Tools?

Problem 3: Render-blocking durch CSS

Auch CSS kann Interaktionen verzögern, wenn der Browser erst stylen muss.

Lösung:

  • CSS optimieren und minimieren
  • Nicht genutztes CSS entfernen (PurgeCSS, UnCSS)

Mein INP-Horror-Projekt

Ein Blog-Kunde hatte INP bei 650ms. Nach Analyse: Ein Social-Sharing-Plugin.

Dieses Plugin lud:

  • 4 verschiedene JavaScript-Bibliotheken
  • Icons von 8 verschiedenen Social Networks
  • Echtzeitdaten von Facebook, Twitter, LinkedIn (Share-Counts)

Das Irre: Sharing-Buttons wurden in 12 Monaten 127 Mal geklickt. Bei 120.000 monatlichen Besuchern.

Wir haben das Plugin entfernt, einfache Social-Links eingefügt. INP fiel auf 120ms. Niemand vermisste die Buttons.

Lektion: Jedes Feature auf Ihrer Website hat einen Performance-Preis. Lohnt es sich?

Core Web Vital #3: CLS (Cumulative Layout Shift)

Was misst CLS?

CLS misst visuelle Stabilität. Springen Elemente auf Ihrer Seite während des Ladens herum?

Sie kennen das: Sie wollen auf einen Link klicken, aber im letzten Moment lädt ein Bild und schiebt alles nach unten. Sie klicken auf die falsche Stelle. Nervig, oder?

Google hasst das genauso wie Sie.

Die Grenzwerte

CLS ist die einzige Metrik ohne Zeit-Einheit. Es ist ein Score:

  • Gut (Grün): ≤ 0,1
  • Verbesserungsbedürftig (Orange): 0,1 - 0,25
  • Schlecht (Rot): > 0,25

Was bedeutet 0,1? Vereinfacht: 10% des Viewports haben sich unerwartet verschoben. Je höher, desto chaotischer.

Warum ist CLS wichtig?

Drei Gründe:

  1. User Experience: Layout Shifts sind objektiv frustrierend
  2. Versehentliche Klicks: Nutzer klicken auf falsche Dinge (schlecht für UX, schlecht für Ads-Revenue wenn sie versehentlich auf Ads klicken)
  3. Mobile: Auf Smartphones noch kritischer – kleinerer Screen, präzisere Klicks nötig

Das krasseste CLS-Beispiel, das ich je gesehen habe:

News-Website. CLS-Score: 0,87. Warum? 16 Ads, die alle nacheinander laden und den Content verschieben. Beim Scrollen war es wie ein Erd beben.

Nutzer-Beschwerde auf Twitter: “Ich hab versucht, den Artikel zu lesen. Beim dritten Layout-Shift hab ich aufgegeben und die Seite geschlossen.”

Das ist kein SEO-Problem mehr. Das ist ein Business-Problem.

Häufigste CLS-Probleme

Problem 1: Bilder und Videos ohne Dimensionen

Wenn Sie kein width und height für Bilder angeben, weiß der Browser nicht, wie viel Platz er reservieren soll. Bild lädt → Layout springt.

Lösung:

<!-- Schlecht -->
<img src="hero.jpg" alt="Hero Image">

<!-- Gut -->
<img src="hero.jpg" alt="Hero Image" width="1200" height="600">

Oder mit CSS:

img {
  aspect-ratio: 16/9;
  width: 100%;
  height: auto;
}

Problem 2: Dynamisch eingefügte Inhalte (Ads, Embeds)

Ads sind der CLS-Killer Nummer 1. Sie laden asynchron, haben keine feste Größe, und schieben alles.

Lösung:

  • Reservieren Sie festen Platz für Ad-Slots
  • Nutzen Sie min-height für Embed-Container
  • Laden Sie Ads früher im Rendering-Prozess

Problem 3: Web Fonts (FOUT/FOIT)

“Flash of Unstyled Text” oder “Flash of Invisible Text” – beide können CLS verursachen.

Lösung:

  • font-display: optional oder swap nutzen
  • Fonts preloaden
  • System-Fonts als Fallback mit ähnlichen Metriken

Problem 4: Dynamische Banner/Notifications

Cookie-Banner, Newsletter-Popups, die von oben reinschieben und alles verschieben.

Lösung:

  • Overlay statt Push (mit position: fixed)
  • Wenn Push, dann komplett geladen vor erstem Paint

Mein CLS-Albtraum

Ein E-Commerce-Kunde hatte CLS von 0,42. Analyse zeigte: Ihr Cookie-Banner.

Dieser Banner wurde via JavaScript 800ms nach Page Load injiziert und schob den gesamten Content nach unten. Jeder. Einzelne. Besucher. erlebte einen massiven Layout-Shift beim Seitenaufruf.

Wir haben den Banner auf position: fixed gesetzt (Overlay statt Push). CLS fiel auf 0,06. Rankings stiegen innerhalb von 3 Wochen merklich an.

Cost of Change: 20 Minuten CSS-Änderung. Impact: Messbar bessere Rankings.

Wie messe ich Core Web Vitals? Die Tools

Es gibt zwei Arten von Daten: Lab Data (simuliert) und Field Data (echte Nutzer).

Field Data: Real User Monitoring

Google Search Console (kostenlos)

  • Zeigt Ihre echten Core Web Vitals-Daten
  • “Erfahrung” → “Core Web Vitals”
  • Sehen Sie, welche URLs Probleme haben
  • Nachteil: Braucht genug Traffic (ca. 1000+ Besucher/Monat)

Chrome User Experience Report (CrUX)

  • Die Daten, die Google für Rankings nutzt
  • Öffentlich zugänglich via PageSpeed Insights
  • Zeigt 28-Tage-Durchschnitt echter Chrome-Nutzer

Mein Tipp: Google Search Console ist Ihr Ausgangspunkt. Wenn Google sagt, Ihre Seite hat CWV-Probleme, dann ist das Ihre Priorität.

Lab Data: Testing Tools

PageSpeed Insights (kostenlos)

Lighthouse (Chrome DevTools)

  • Direkt in Chrome eingebaut (F12 → Lighthouse-Tab)
  • Detaillierte Analyse
  • Vorsicht: Lab-Daten simulieren Throttled 4G. Echte Nutzer können besser/schlechter sein.

WebPageTest

Meine Test-Routine

Für jede Website, die ich optimiere:

  1. Google Search Console: Welche URLs haben laut echten Nutzern Probleme?
  2. PageSpeed Insights: Diese URLs einzeln testen, Field Data + Lab Data vergleichen
  3. Chrome DevTools Lighthouse: Detailanalyse, konkrete Issues identifizieren
  4. Fix implementieren
  5. Lighthouse erneut: Hat es funktioniert?
  6. 4 Wochen warten: Google Search Console aktualisiert monatlich (CrUX ist 28-Tage-Rolling)
  7. Search Console checken: Sind die Probleme weg?

Core Web Vitals optimieren: Meine Schritt-für-Schritt-Anleitung

Sie haben schlechte Werte. Was jetzt?

Schritt 1: Identifizieren Sie den Flaschenhals

Nicht alle drei Metriken haben bei Ihnen Probleme. Fokussieren Sie sich auf die Schlimmste.

In Google Search Console:

  • Gehen Sie zu “Erfahrung” → “Core Web Vitals”
  • Welche Metrik zeigt die meisten “schlechten URLs”?
  • Klicken Sie auf “Bericht öffnen” für diese Metrik

Schritt 2: Analysieren Sie eine repräsentative URL

Nehmen Sie eine URL aus der “schlechten” Liste und testen Sie sie in PageSpeed Insights.

Scrollen Sie zu “Diagnose”:

  • Bei LCP: “Largest Contentful Paint element” zeigt, welches Element langsam ist
  • Bei INP: “Minimize main thread work” zeigt lange Tasks
  • Bei CLS: “Avoid large layout shifts” zeigt Problem-Elemente

Schritt 3: Low-Hanging-Fruit zuerst

Oft gibt es ein oder zwei Dinge, die 80% des Problems verursachen.

Meine Top 5 Quick Wins:

  1. Bilder komprimieren: 10 Minuten Arbeit, massive LCP-Verbesserung
  2. Web Font lokal hosten: 5 Minuten, bessere LCP + CLS
  3. Unused CSS/JS entfernen: Nutzen Sie Coverage-Tool in Chrome DevTools
  4. Browser-Caching aktivieren: .htaccess-Änderung, sofortige Verbesserung für Returning Visitors
  5. CDN aktivieren: Cloudflare Free-Plan, 15 Minuten Setup

Schritt 4: Technische Deep-Dives

Wenn Quick Wins nicht reichen:

Für LCP:

  • Server-Upgrade erwägen
  • Lazy Loading für Below-the-Fold-Bilder
  • Preload für kritische Ressourcen
  • HTTP/2 oder HTTP/3 aktivieren

Für INP:

  • JavaScript-Bundle-Analyser nutzen (webpack-bundle-analyzer)
  • Code Splitting implementieren
  • Third-Party-Scripts auf Diät setzen

Für CLS:

  • Alle Images/Videos mit aspect-ratio
  • Ad-Slots mit festen Dimensionen
  • Animations nur mit transform und opacity (kein width, height, margin)

Schritt 5: Testen, messen, iterieren

Performance-Optimierung ist nie “fertig”.

Mein Prozess:

  • Änderung implementieren
  • Lighthouse vorher/nachher vergleichen
  • Wenn besser: Deployen
  • Nach 4 Wochen: Google Search Console prüfen
  • Nächste Problem-URL angehen

Häufige Fragen zu Core Web Vitals

F: Muss ich 100/100 in Lighthouse erreichen?

A: Nein. Ein Score von 90+ ist exzellent. Über 95 zu kommen bedeutet oft massiven Aufwand für minimalen Gain. Fokussieren Sie sich darauf, im grünen Bereich zu sein.

F: Warum sind meine Lighthouse-Scores besser als meine Search Console-Daten?

A: Lighthouse simuliert ideale Bedingungen. Search Console zeigt echte Nutzer mit langsamen Handys, schlechtem Netz, Ad-Blockern, etc. Field Data ist immer die Wahrheit.

F: Meine Website ist schnell auf meinem Laptop, aber Search Console sagt was anderes?

A: Ihr Laptop ist nicht repräsentativ. Die meisten Nutzer haben schlechtere Hardware, langsameres Internet. Google misst primär mobile Nutzer.

F: Kann ich Core Web Vitals ignorieren, wenn mein Content extrem gut ist?

A: Kommt drauf an. In Nischen mit wenig Konkurrenz: vielleicht. In kompetitiven Bereichen: nein. Aber warum sollten Sie Traffic verschenken?

F: Wie oft aktualisiert Google die Core Web Vitals-Daten?

A: CrUX (Chrome User Experience Report) nutzt einen 28-Tage-Rolling-Average. Änderungen werden also nicht sofort sichtbar. Geduld!

Der ROI von Core Web Vitals: Zahlen aus meiner Praxis

Ich bin Geschäftsfrau. Ich verkaufe Core Web Vitals nicht mit “Google will das”, sondern mit ROI.

3 Projekte, 3 ROI-Beispiele:

Projekt 1: E-Commerce (Sportartikel)

  • Investment: 80h Entwicklerzeit (~ 6.400 EUR)
  • LCP: 4,2s → 1,8s | INP: 420ms → 180ms | CLS: 0,31 → 0,05
  • Ergebnis (3 Monate später): Organischer Traffic +41%, Conversion Rate +18%
  • Zusätzlicher Monatsumsatz: ~12.000 EUR
  • ROI: Amortisierung in 3 Wochen

Projekt 2: SaaS-Plattform (B2B)

  • Investment: 120h (~ 9.600 EUR)
  • Problem war primär INP (JavaScript-Heavy-App)
  • Ergebnis: Trial-Signups +23%, Absprungrate bei Registration -31%
  • Zusätzliche MRR: ~8.000 EUR
  • ROI: Amortisierung in 5 Wochen

Projekt 3: Blog/Content-Site

  • Investment: 20h (~ 1.600 EUR, primär Bild-Optimierung)
  • LCP: 5,1s → 2,1s
  • Ergebnis: Traffic +28%, Ad Revenue +26%, Session Duration +34%
  • Zusätzliche Monatseinnahmen: ~1.200 EUR
  • ROI: Amortisierung in 6 Wochen

Pattern: In allen Fällen hat sich die Investition in unter 2 Monaten amortisiert. Danach sind es pure Gewinne.

Tools & Ressourcen (meine Favoriten)

Kostenlose Tools:

Bild-Optimierung:

  • Squoosh (Browser-basiert, Privacy-friendly)
  • TinyPNG
  • ImageOptim (Mac)

Erweitert:

Weiterlernen:

Fazit: Core Web Vitals sind kein Hexenwerk

Als ich 2021 zum ersten Mal mit Core Web Vitals konfrontiert wurde, dachte ich: “Ich bin SEO-Beraterin, keine Entwicklerin. Das ist zu technisch.”

Heute weiß ich: Man muss kein Developer sein, um Core Web Vitals zu verstehen und zu verbessern. Man muss nur:

  1. Verstehen, was die Metriken messen
  2. Messen, wo man steht
  3. Priorisieren, was den größten Impact hat
  4. Fixen (oder fixen lassen)
  5. Überwachen, dass es dauerhaft gut bleibt

Die meisten Probleme haben einfache Lösungen: Bilder komprimieren, Fonts optimieren, unnötige Scripts entfernen. Kein Rocket Science.

Und der Impact? Messbar. In Rankings, Traffic, Conversions, Umsatz.

Im nächsten Artikel schauen wir uns an, wie Sie Ihre wichtigsten On-Page-Elemente optimieren: Title Tags optimieren. Die wichtigsten 60 Zeichen Ihrer gesamten Website.

Haben Sie Fragen zu Core Web Vitals? Drop mir einen Kommentar!

Lisa Bergmann hilft Unternehmen, schnellere Websites zu bauen – nicht um technisch zu prahlen, sondern um mehr Geld zu verdienen. Sie glaubt daran, dass jede investierte Stunde in Performance sich in messbarem ROI auszahlt.

Verwandte Artikel