Core Web Vitals optimieren: LCP, INP und CLS verbessern (Leitfaden 2026)

Die Core Web Vitals sind drei messbare Kennzahlen, mit denen Google die tatsächliche Nutzererfahrung einer Seite bewertet: Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität. Sie fließen als Teil des „Page Experience"-Signals in das Ranking ein. Wichtig zu verstehen: Sie sind kein magischer Ranking-Boost, sondern ein Tiebreaker. Bei zwei inhaltlich vergleichbaren Seiten gewinnt die schnellere, stabilere — und schlechte Werte kosten dich vor allem über die Absprungrate Conversions.

Seit März 2024 hat INP (Interaction to Next Paint) die alte Metrik FID (First Input Delay) abgelöst. Das ist die wichtigste Änderung der letzten Jahre und der Grund, warum viele Seiten, die früher problemlos durchkamen, heute durchfallen. Laut dem HTTP Archive Web Almanac führte die Umstellung von FID auf INP zu einem spürbaren Rückgang der Pass-Rate auf Mobilgeräten — in der Größenordnung von einigen Prozentpunkten. Der Grund: FID maß nur die Verzögerung vor der allerersten Interaktion. INP bewertet dagegen jede Interaktion über die gesamte Sitzung und meldet einen repräsentativen Wert. Seiten, die beim ersten Klick schnell reagierten, danach aber unter schwerfälligem JavaScript litten, fallen jetzt auf.

Die drei Metriken im Überblick

• LCP (Largest Contentful Paint): Wie lange dauert es, bis das größte sichtbare Element (meist ein Hero-Bild oder eine Headline) gerendert ist? Misst die wahrgenommene Ladegeschwindigkeit.
• INP (Interaction to Next Paint): Wie schnell reagiert die Seite sichtbar auf Klicks, Taps und Tastatureingaben? Misst die Reaktionsfähigkeit über die gesamte Sitzung.
• CLS (Cumulative Layout Shift): Wie stark verschieben sich Elemente unerwartet während des Ladens? Misst die visuelle Stabilität — also ob dir der Button unter dem Finger wegspringt.

Neben diesen drei Kern-Metriken gibt es Diagnose-Werte, die du fürs Debugging brauchst, ohne dass sie selbst ins Ranking einfließen: TTFB (Time to First Byte) zeigt, wie lange der Server bis zum ersten Byte braucht, und FCP (First Contentful Paint) markiert den Moment, in dem der erste Inhalt sichtbar wird. Beide sind Vorboten eines schlechten LCP — ein hohes TTFB zieht praktisch jede nachgelagerte Metrik nach unten. Wer das Thema strategisch angeht, behandelt Performance nicht als einmaliges Projekt, sondern als laufenden Teil der technischen SEO. Denn die Vitals werden mit echten Nutzerdaten gemessen, und die ändern sich, sobald du neue Skripte, Tracking-Tags oder Plugins einbaust.

Google teilt jede Metrik in drei Stufen ein: „Gut", „Verbesserung nötig" und „Schlecht". Entscheidend ist, dass die Bewertung am 75. Perzentil erfolgt — das heißt, 75 % aller Seitenaufrufe müssen im grünen Bereich liegen, damit die Seite besteht. Ein guter Laborwert auf deinem schnellen Entwickler-Laptop reicht nicht; es zählt die Erfahrung deiner realen Besucher, oft auf älteren Smartphones mit langsamer Mobilfunkverbindung.

Eine Seite gilt nur dann insgesamt als bestanden, wenn alle drei Metriken den Wert „Gut" erreichen. Ein hervorragendes LCP rettet dich nicht, wenn dein INP bei 600 ms liegt. Plane deshalb keine isolierten Einzelmaßnahmen, sondern arbeite alle drei Achsen parallel ab. Ein zweiter Punkt wird oft übersehen: Mobil und Desktop werden getrennt bewertet. Die meisten Seiten bestehen auf dem Desktop locker und scheitern mobil — schwächere CPUs, langsamere Verbindungen und kleinere Viewports machen denselben Code spürbar träger. Optimiere deshalb immer zuerst für das Mobil-Profil; was dort grün ist, ist auf dem Desktop fast sicher ebenfalls grün.

Bevor wir in die einzelnen Metriken einsteigen, lohnt sich ein Blick auf die Reihenfolge. Wer effizient Core Web Vitals optimieren will, arbeitet nicht alphabetisch, sondern nach Wirkung. Drei Prinzipien geben die Richtung vor:

1. Erst messen, dann anfassen. Jede Stunde, die du in ein bereits gutes LCP steckst, während eigentlich der INP rot ist, ist verschwendet. Die Felddaten sagen dir, welche Metrik auf welcher Seitengruppe blockiert — danach priorisierst du.
2. Die teuersten Bytes zuerst. In den meisten Projekten dominieren zwei Ressourcen die Ladezeit: das größte Bild und das ausgelieferte JavaScript. Wer diese beiden in den Griff bekommt, verbessert LCP und INP gleichzeitig — und CLS folgt oft als Nebeneffekt sauberer Layout-Disziplin.
3. Im Build verankern, nicht von Hand pflegen. Eine einmalige Optimierung hält keine drei Deployments. Bildkompression, Code-Splitting und reservierte Layout-Größen gehören in den Build-Prozess und in eine Linting-Regel, nicht in eine To-do-Liste.

Die folgenden drei Abschnitte gehen LCP, INP und CLS in genau dieser Wirkungs-Logik durch — mit konkreten Code-Mustern, die du direkt übernehmen kannst. Wenn du nur begrenzt Zeit hast, fang beim INP an: Das ist 2026 die Metrik, an der die meisten Seiten scheitern.

Das LCP-Problem ist fast immer ein Bild- oder Ressourcen-Problem. Das größte Element wird zu spät entdeckt, zu spät geladen oder zu groß ausgeliefert. Die LCP-Zeit zerfällt in vier Phasen, und es lohnt sich, sie zu kennen: TTFB (Server-Antwort), Resource Load Delay (Zeit, bis der Browser die LCP-Ressource überhaupt entdeckt), Resource Load Time (das eigentliche Herunterladen) und Element Render Delay (bis das Element gemalt wird). In der Praxis steckt das Problem meist im Load Delay — der Browser findet das Hero-Bild erst spät, weil es tief im DOM steht oder per CSS-Hintergrund geladen wird. So bringst du LCP unter 2,5 Sekunden:

1. Bilder ernsthaft optimieren

• Moderne Formate: Liefere WebP oder AVIF statt JPEG/PNG. Das spart oft mehr als die Hälfte der Dateigröße bei gleicher Qualität. Laut Web Almanac liegt die Nutzung moderner Formate trotzdem noch deutlich unter dem Möglichen — hier liegt also Potenzial.
• Responsive Größen: Nutze srcset und sizes, damit ein Smartphone nicht die 2560-px-Desktop-Variante herunterlädt, sondern eine passend kleine Datei.
• LCP-Bild priorisieren: Setze beim Hero-Bild fetchpriority="high" und verzichte hier explizit auf loading="lazy" — Lazy Loading gehört unter den Fold, niemals auf das LCP-Element. Ein faul geladenes Hero-Bild ist eine der häufigsten Ursachen für ein schlechtes LCP überhaupt.
• Vorab laden: Ein Preload-Hint verkürzt die Zeit bis zur Entdeckung der Ressource spürbar.

Ein konkretes Beispiel für ein sauber priorisiertes Hero-Bild im Markup:

<link rel="preload" as="image"
      href="/hero.avif" type="image/avif"
      fetchpriority="high">

<img src="/hero.avif"
     width="1280" height="720"
     fetchpriority="high"
     alt="...">

Wichtig: Preload nur für das eine Element, das wirklich das LCP ist — preloadest du zu viel, konkurrieren die Ressourcen um Bandbreite und das LCP wird langsamer statt schneller.

2. Render-blockierende Ressourcen entfernen

Großes, im <head> blockierendes CSS und synchrones JavaScript verzögern den ersten Render. Inline-Critical-CSS für den sichtbaren Bereich, den Rest asynchron nachladen. Schriften mit font-display: swap ausliefern und die wichtigste Schrift preloaden, damit kein unsichtbarer Text (FOIT) entsteht. Drittanbieter-CSS von Schrift- oder Icon-Diensten ist hier ein häufiger versteckter Blocker — selbst hosten ist fast immer schneller als der Umweg über eine fremde Domain mit zusätzlichem DNS- und TLS-Handshake.

3. Server-Antwortzeit (TTFB) senken

Wenn der Server lange braucht, hat das Bild keine Chance. Setze auf Caching, ein CDN mit Edge-Standorten nahe deiner Zielgruppe und serverseitiges Rendering oder statische Generierung statt reinem Client-Side-Rendering. Eine Time to First Byte deutlich unter einer halben Sekunde ist das Ziel. Bei dynamischen Seiten hilft ein Cache vor der Datenbank, bei statischen Inhalten Pre-Rendering zur Build-Zeit. Genau an dieser Architektur-Ebene setzt saubere technische Optimierung an — eine schöne Frontend-Optimierung verpufft, wenn der Server der Flaschenhals ist.

INP ist 2026 die Metrik, an der die meisten Seiten scheitern, weil sie direkt von der JavaScript-Last abhängt. Jede Interaktion durchläuft drei Phasen: Input Delay (Wartezeit, bis der Browser den Event verarbeiten kann), Processing Time (Ausführung des Event-Handlers) und Presentation Delay (Zeit bis zum nächsten sichtbaren Frame). INP misst alle drei — anders als das alte FID, das nur den Input Delay erfasste. Bei modernen Single-Page-Anwendungen ist der häufigste Übeltäter die Hydration: Der Browser hat das HTML längst gerendert, blockiert aber den Hauptthread minutenlang, weil er einen riesigen JavaScript-Bundle parst und Event-Listener anhängt. In dieser Phase fühlen sich Klicks tot an — die Seite sieht fertig aus, reagiert aber nicht.

So senkst du INP unter 200 ms

1. JavaScript-Bundle verkleinern: Code-Splitting und Tree-Shaking sind die Basis. Lade nur den Code, den die aktuelle Route wirklich braucht, und ziehe schwere Bibliotheken (Datums-, Chart-, Editor-Libs) per dynamischem Import erst nach, wenn sie gebraucht werden. Weniger geparstes JavaScript heißt direkt weniger Hauptthread-Blockade.
2. Hydration aufteilen oder vermeiden: Hydratisiere nicht die ganze Seite auf einmal. Partielle oder selektive Hydration (Islands-Architektur) hydratisiert nur die wirklich interaktiven Komponenten; statische Bereiche bleiben reines HTML. Frameworks bieten dafür heute Streaming-SSR und verzögerte Hydration an.
3. Lange Tasks aufbrechen: Der Hauptthread ist single-threaded. Eine JavaScript-Aufgabe über 50 ms blockiert jede Interaktion. Teile lange Tasks in kleine Häppchen und gib regelmäßig an den Browser zurück, damit er auf Klicks reagieren kann. Ein einfaches Muster dafür:

async function processChunks(items) {
  for (const item of items) {
    doWork(item);
    // Hauptthread freigeben, damit
    // Klicks dazwischen verarbeitet werden
    if (scheduler.yield) await scheduler.yield();
    else await new Promise(r => setTimeout(r, 0));
  }
}

4. Nicht-kritisches Skript verzögern: Analytics, Chat-Widgets, A/B-Test-Tools und Cookie-Banner sind die üblichen Verdächtigen. Lade sie mit defer, async oder erst nach der ersten Interaktion.
5. Third-Party-Skripte ausmisten: Jedes Tracking-Pixel und jeder Tag-Manager-Container kostet Hauptthread-Zeit. Prüfe per Audit, welche Skripte wirklich gebraucht werden — oft lässt sich die Hälfte streichen oder serverseitig ersetzen.
6. Layout-Thrashing vermeiden: Wechselndes Lesen und Schreiben von DOM-Eigenschaften (z. B. offsetHeight abfragen und direkt danach Styles setzen) erzwingt teure Reflows. Erst alles lesen, dann alles schreiben.
7. DOM klein halten: Riesige DOM-Bäume mit zehntausenden Knoten verteuern jede Style-Berechnung. Virtualisiere lange Listen, statt alles auf einmal zu rendern.

Der pragmatische Einstieg: Identifiziere mit Felddaten zuerst deine schlechtesten Interaktionen und optimiere gezielt diese Code-Pfade, statt blind die gesamte Codebasis zu refactoren. Oft sind es ein, zwei Handler — etwa ein überladener Klick auf das Hauptmenü oder ein Filter, der bei jedem Tastendruck die komplette Liste neu rendert.

CLS misst, wie stark Elemente während des Ladens herumspringen. Der Klassiker: Du willst auf einen Button tippen, ein nachgeladenes Banner schiebt das Layout nach unten, und du klickst auf etwas anderes. Die gute Nachricht — CLS ist meist die am schnellsten zu lösende Metrik, weil die Ursachen überschaubar sind. Technisch berechnet sich der Wert aus Impact Fraction (wie viel des Viewports sich verschiebt) mal Distance Fraction (wie weit). Schon kleine, früh geladene Reservierungen drücken beide Faktoren gegen null.

Die wichtigsten Fixes

• Bild- und Video-Dimensionen reservieren: Setze immer width und height (oder ein aspect-ratio in CSS), damit der Browser den Platz reserviert, bevor das Medium geladen ist.
• Platz für Werbung und Embeds: Reserviere feste Container-Höhen für Ad-Slots, iframes und dynamisch nachgeladene Inhalte. Springende Anzeigen sind die häufigste CLS-Ursache.
• Schriften ohne Sprung laden: Webfonts, die spät laden, verschieben Text. font-display: swap plus eine gut abgestimmte Fallback-Schrift (mit size-adjust) reduziert den Sprung.
• Neue Inhalte nie über bestehende schieben: Banner, Cookie-Hinweise oder „Du hast neue Nachrichten"-Leisten gehören per Overlay oder an reservierte Positionen — nicht mitten in den Lesefluss.
• CSS-Transformationen statt Layout-Eigenschaften animieren: Animiere mit transform und opacity statt mit top, left oder height, die das Layout neu berechnen.

Ein bewährtes Muster, um Platz für ein Bild reserviert zu halten, bevor es lädt:

/* CSS: Seitenverhältnis vorab reservieren */
.media {
  aspect-ratio: 16 / 9;
  width: 100%;
}

<!-- HTML: Dimensionen direkt am Element -->
<img src="teaser.avif"
     width="800" height="450"
     loading="lazy" alt="...">

Eine kleine Disziplin im Markup zahlt sich hier enorm aus: Wer von Anfang an Größen reserviert, hält CLS fast automatisch unter 0,1. Achte zusätzlich auf nachträglich injizierte Inhalte — A/B-Test-Tools, die Inhalte austauschen, und personalisierte Banner sind die typischen CLS-Quellen, die im Labortest nicht auffallen, in den Felddaten aber zuschlagen.

Der häufigste Fehler beim Core Web Vitals optimieren ist, nur Labordaten anzuschauen. Es gibt zwei grundverschiedene Datenquellen, und du brauchst beide.

Felddaten (das, was zählt)

Felddaten stammen vom Chrome User Experience Report (CrUX) — echte Messungen von echten Chrome-Nutzern. Genau diese Daten nutzt Google fürs Ranking. Sieh sie hier:

• Google Search Console → Bericht „Core Web Vitals": zeigt URL-Gruppen, die durchfallen, getrennt nach Mobil und Desktop. Der beste Startpunkt, um Problemseiten zu finden — Search Console fasst ähnliche URLs automatisch zu Gruppen zusammen, sodass ein Fix oft hunderte Seiten auf einmal löst.
• PageSpeed Insights: zeigt oben die CrUX-Felddaten (28-Tage-Fenster) und darunter den Lighthouse-Labortest. Die Lücke zwischen beiden Blöcken ist selbst eine Information: Sind die Felddaten deutlich schlechter als das Labor, leidet deine reale Nutzerschaft unter langsameren Geräten oder Netzen, als dein Test annimmt.
• CrUX-Dashboard / BigQuery: für tieferes Monitoring über Zeit und für den Vergleich mit Wettbewerbern auf Origin-Ebene.

Labordaten (zum Debuggen)

Labordaten kommen aus einer kontrollierten Testumgebung — etwa Lighthouse in den Chrome DevTools oder PageSpeed Insights. Sie sind reproduzierbar und ideal zum Debuggen einzelner Probleme. Aber: Lighthouse misst keinen echten INP, weil dafür echte Nutzerinteraktionen nötig sind. Für INP sind Felddaten und das Web-Vitals-Overlay in den DevTools (Performance-Tab) die richtigen Werkzeuge. Wer kontinuierlich messen will, baut zusätzlich ein eigenes Real-User-Monitoring über die web-vitals-Bibliothek ein — sie liefert dieselben Metriken wie CrUX, aber in Echtzeit und für jede einzelne Seite statt nur für aggregierte Gruppen.

Der praktische Workflow

1. In der Search Console die durchfallenden URL-Gruppen identifizieren.
2. Eine Beispiel-URL in PageSpeed Insights analysieren — Felddaten oben, Lighthouse-Diagnose unten.
3. Mit den Chrome DevTools (Performance-Aufzeichnung, INP-Overlay, gedrosselte CPU und Verbindung) die konkrete Ursache nachstellen.
4. Fix deployen, dann geduldig sein: CrUX nutzt ein rollierendes 28-Tage-Fenster. Es dauert Wochen, bis sich Verbesserungen in den Felddaten und in der Search Console niederschlagen.

Diese Geduld ist wichtig: Wer nach drei Tagen frustriert ist, weil sich der Felddaten-Wert nicht bewegt, übersieht das 28-Tage-Fenster. Performance ist wie SEO ein Mittelstreckenlauf — wie auch beim Unterschied zwischen klassischem und KI-getriebenem Suchen, den wir im Ratgeber zu Generative Engine Optimization beleuchten.

Eine einmalige Optimierung verpufft, sobald das nächste Marketing-Tool eingebaut wird. Performance ist ein Prozess, kein Projekt. Drei Prinzipien, mit denen die Werte langfristig grün bleiben:

• Performance-Budget setzen: Lege fest, wie viel JavaScript- und Bild-Gewicht eine Seite maximal haben darf. Jedes neue Feature muss in dieses Budget passen — oder etwas anderes muss weichen.
• Monitoring automatisieren: Lighthouse-CI oder ein Real-User-Monitoring-Tool im Deployment-Prozess fängt Regressionen ab, bevor sie live gehen. So merkst du es, wenn ein neues Plugin das LCP um eine Sekunde verschlechtert — nicht erst Wochen später in der Search Console.
• Third-Party-Disziplin: Jeder neue Tag, jedes Widget kostet Performance. Stelle bei jedem Skript die Frage, ob der Mehrwert die Hauptthread-Kosten wert ist.

In der Praxis zahlt sich diese Disziplin direkt aus. Bei Kiwabo haben wir den organischen Traffic um über 210 % gesteigert — eine technisch saubere, schnelle Seite ist dabei die Basis, auf der Content und Rankings überhaupt erst greifen können. Eine langsame oder beim Scrollen ruckelnde Seite verliert Besucher, bevor der beste Inhalt überhaupt eine Chance hat zu überzeugen. Genau deshalb steht die technische Performance bei uns am Anfang jedes Projekts, nicht am Ende.

Wenn du wissen willst, wo deine Seite konkret steht und welche der drei Metriken dich Rankings und Conversions kostet, schauen wir uns das gerne gemeinsam an. Als Berliner Full-Stack-Agentur arbeiten wir genau an der Schnittstelle von technischer SEO und sauberer Web-Entwicklung — und bringen LCP, INP und CLS gemeinsam ins grüne Feld, statt nur an einer Stellschraube zu drehen.