Core Web Vitals verbessern

Praktische Ansatzpunkte, um Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift zu verbessern.

Um Core Web Vitals zu verbessern, muss zuerst anhand realer Nutzungsdaten geklärt werden, welche Metrik überhaupt problematisch ist - erst danach lohnt sich die Ursachensuche auf der betroffenen Seite. LCP betrifft meist den Lade- und Renderpfad des größten sichtbaren Elements, INP die Auslastung des Haupt-Threads bei Interaktionen, CLS unerwartete Layoutverschiebungen. Dieser Artikel ist entlang dieser Reihenfolge aufgebaut: erst prüfen, dann diagnostizieren, dann gezielt beheben.

Welche Werte gelten als gut?

Bewertet wird jeweils das 75. Perzentil aller Seitenaufrufe eines Zeitraums - nicht der Durchschnitt und nicht der beste gemessene Wert. Eine Seite gilt also erst dann als “gut” bei einer Metrik, wenn mindestens drei von vier Aufrufen innerhalb des Gut-Bereichs liegen.

Schritt 1: Felddaten prüfen

Bevor überhaupt optimiert wird, lohnt sich eine Unterscheidung, die häufig übersehen wird: Labordaten (etwa aus Lighthouse oder den Chrome-DevTools) messen eine einzelne, kontrollierte Seitenladung unter festgelegten Bedingungen. Felddaten (etwa aus dem Chrome User Experience Report, kurz CrUX, oder der Google Search Console) fassen tatsächliche Messungen realer Nutzer über einen Zeitraum zusammen. Für Googles Core-Web-Vitals-Bewertung sind die Felddaten maßgeblich - ein guter Laborwert garantiert keinen guten Feldwert, weil reale Nutzer langsamere Geräte, instabilere Verbindungen und andere Ladebedingungen haben, als ein einzelner Labortest sie abbildet.

Labordaten sind deshalb aber nicht nebensächlich - im Gegenteil: Für die Ursachendiagnose auf einer konkreten Seite sind sie besonders wichtig, weil sie reproduzierbar ein einzelnes Element oder Skript als Verursacher identifizieren lassen. Die Search Console zeigt unter “Wichtige Web-Vitals” die realen Feldwerte aggregiert nach URL-Gruppen und Gerätetyp - das ist der richtige Ausgangspunkt, um zu erkennen, welche Metrik auf welchen Seitentypen tatsächlich unter dem Schwellenwert liegt.

Schritt 2: Ursache diagnostizieren

Erst wenn feststeht, welche Metrik auf welchen Seiten schlecht ist, folgt die eigentliche Fehlersuche auf einer betroffenen Einzel-URL:

1. Betroffene URL reproduzieren - in PageSpeed Insights oder den Chrome-DevTools (Performance-Panel).
2. Verantwortliches Element finden - bei LCP: welches Element gilt als LCP-Element? Bei INP: welche Interaktion oder welcher Long Task ist verantwortlich? Bei CLS: welches Element verschiebt sich, und wodurch?
3. Ursache beheben - siehe die metrikspezifischen Tabellen unten.
4. Änderung validieren - siehe den Abschnitt “Änderungen richtig testen” weiter unten.

LCP verbessern

LCP misst, wie lange es dauert, bis der größte sichtbare Inhalt (meist ein Hero-Bild oder ein großer Textblock) gerendert ist. Die Ursache lässt sich meist einer von wenigen Kategorien zuordnen:

Für ein Hero-Bild, das als LCP-Element identifiziert wurde, ist neben preload heute oft auch fetchpriority="high" relevant:

<img src="hero.webp" fetchpriority="high" ...>

Wichtig dabei: nicht jedes Bild sollte preloaded werden. Zu viele preload-Ressourcen erzeugen genau die Konkurrenz um Bandbreite und Haupt-Thread, die man eigentlich vermeiden will - siehe den Abschnitt zu Wechselwirkungen weiter unten.

Ein konkretes Beispiel: Ist das LCP-Element ein Hero-Bild und startet dessen Download erst nach 1,5 Sekunden (weil es zum Beispiel erst nach dem Laden eines CSS-Frameworks im DOM auftaucht), bringt ein moderneres Bildformat allein wenig - entscheidend ist hier zuerst, den Request früher auszulösen.

INP verbessern

INP misst, wie schnell eine Seite auf Nutzerinteraktionen wie Klicks oder Tastatureingaben reagiert, und hat die frühere Metrik First Input Delay (FID) als offiziellen Core Web Vital abgelöst. Der wesentliche Unterschied: FID maß nur die erste Interaktion, INP bewertet Interaktionen über den gesamten Seitenbesuch hinweg.

Das zugrunde liegende Modell lässt sich an einem Klick durchspielen: Führt der Browser gerade JavaScript auf dem Haupt-Thread aus, kann er währenddessen nicht unmittelbar auf einen Klick reagieren.

Klick
 ↓
Haupt-Thread noch beschäftigt
 ↓
Event-Handler wird ausgeführt
 ↓
DOM-/Layout-Arbeit
 ↓
nächster Paint

Je länger die Kette dauert, desto schlechter der INP-Wert. Typische Ursachen dieser Verzögerung:

• Lange JavaScript-Aufgaben (“Long Tasks”), die den Haupt-Thread blockieren
• Große JavaScript-Bundles, insbesondere beim initialen Laden
• Framework-Hydration (bei React, Vue & Co., wenn viel DOM nachträglich interaktiv gemacht wird)
• Drittanbieter-Skripte wie Tracking, Werbung oder Chat-Widgets - eine der häufigsten INP-Ursachen, weil sie außerhalb der eigenen Kontrolle liegen
• Aufwendige DOM-Manipulation oder komplizierte Event-Handler, insbesondere bei Formularen

Entsprechende Gegenmaßnahmen: lange Aufgaben in kleinere Einheiten aufteilen, nicht kritisches JavaScript verzögert oder asynchron laden, Drittanbieter-Skripte kritisch prüfen statt als unveränderlich hinzunehmen, und Event-Handler auf unnötige Arbeit untersuchen.

CLS verbessern

CLS misst unerwartete Layoutverschiebungen während des Ladens. Häufige Ursachen und Lösungen:

• Bildern und Videos feste width- und height-Attribute oder ein aspect-ratio mitgeben
• Platz für dynamisch nachgeladene Inhalte (z. B. Werbeanzeigen oder Consent-Banner) vorab reservieren
• Web Fonts mit font-display: optional oder passenden Fallback-Metriken einbinden, um Schriftwechsel-Sprünge zu vermeiden

Ein Sonderfall, der oft übersehen wird: Inhalte, die per JavaScript oberhalb bereits gerenderten Contents eingefügt werden - etwa ein nachträglich eingeblendetes Cookie-Banner am oberen Seitenrand - verursachen typischerweise den größten Layout-Shift-Wert, weil dabei der gesamte sichtbare Inhalt darunter verschoben wird.

Nicht jede sichtbare Bewegung zählt dabei als CLS: Layoutverschiebungen, die unmittelbar durch eine Nutzerinteraktion ausgelöst werden (etwa das Ausklappen eines Akkordeons per Klick), können von der Bewertung ausgenommen sein.

Wechselwirkungen zwischen den drei Metriken

Die drei Metriken lassen sich nicht immer unabhängig voneinander optimieren. preload für zu viele Ressourcen verbessert zwar potenziell LCP, kann aber die Netzwerk- und Hauptthread-Auslastung beim Start erhöhen und dadurch INP in der kritischen Anfangsphase verschlechtern. Ebenso kann das Reservieren von Platz für nachgeladene Werbeflächen (gut für CLS) dazu führen, dass die Seite beim ersten Rendern mehr leeren Raum enthält, was das LCP-Element weiter nach unten verschiebt. Optimierung sollte deshalb immer alle drei Metriken gemeinsam im Blick behalten, nicht eine isoliert auf Kosten der anderen.

Mobile und Desktop getrennt betrachten

Core-Web-Vitals-Werte unterscheiden sich zwischen mobilen und Desktop-Nutzern oft erheblich, da mobile Geräte im Schnitt weniger Rechenleistung haben und häufiger über langsamere oder instabilere Netzwerke verbunden sind. Google bewertet und meldet beide getrennt - ein Problem kann auf Mobile und Desktop zudem völlig unterschiedliche Ursachen haben. Statt sich pauschal an der schwächeren Plattform zu orientieren, sollte die Priorisierung danach gehen, wo schlechte Werte tatsächlich viele reale Nutzer betreffen: Eine Seite mit 99 % mobilem Traffic sollte anders priorisiert werden als eine mit überwiegend Desktop-Nutzern, selbst wenn beide auf einer Plattform schwächer abschneiden.

Änderungen richtig testen

Eine Änderung lässt sich im Labortest (Lighthouse, PageSpeed Insights, DevTools) sofort überprüfen. In den aggregierten Felddaten (CrUX, Search Console) werden Verbesserungen dagegen erst mit Verzögerung sichtbar, weil diese auf einem rollierenden Zeitraum realer Nutzungsdaten beruhen. Wer eine Optimierung ausliefert und am nächsten Tag in der Search Console nachschaut, sieht deshalb häufig noch keine Veränderung - das bedeutet nicht, dass die Maßnahme wirkungslos war, sondern nur, dass die Felddaten noch nicht nachgezogen sind.

Welche Optimierung zuerst?

Nicht jede Website hat bei allen drei Metriken Probleme, und die Metrik mit dem größten Abstand zum Schwellenwert ist nicht automatisch die mit dem größten praktischen Nutzen. Sinnvoller ist eine Priorisierung nach drei Faktoren:

1. Reichweite - wie viele URLs oder Sitzungen sind betroffen? Ein schlechter LCP-Wert auf 50 selten besuchten Seiten wiegt anders als ein mittelmäßiger INP-Wert auf einer stark frequentierten Kernseite.
2. Schwere - wie weit liegt der Wert über dem Schwellenwert?
3. Aufwand - wie leicht lässt sich die konkrete Ursache beheben? Ein einzelnes falsch gesetztes loading="lazy" ist in Minuten korrigiert, eine JavaScript-Architektur, die INP verschlechtert, unter Umständen nicht.

Erst aus Reichweite, Schwere und Aufwand zusammen ergibt sich eine belastbare Reihenfolge - nicht aus der Distanz zum Schwellenwert allein.

Häufige Fehler

• Nur Labordaten (Lighthouse) prüfen und Felddaten (CrUX, Search Console) ignorieren, obwohl nur Felddaten die tatsächliche Bewertung widerspiegeln.
• Lazy-Loading pauschal auf alle Bilder anwenden, einschließlich des LCP-Elements.
• Drittanbieter-Skripte als “unveränderlich” behandeln, obwohl sie oft die Hauptursache schlechter INP-Werte sind.
• Eine Metrik isoliert optimieren, ohne die Auswirkung auf die anderen beiden zu prüfen.
• Nach einer Änderung sofort in den Felddaten nach einer Verbesserung suchen, statt die Verzögerung durch den rollierenden Zeitraum einzuplanen.

Core Web Vitals in WordPress

Auf WordPress-Websites tauchen bestimmte Ursachen besonders häufig auf, weil sie aus dem Zusammenspiel von Theme, Plugins und Backend entstehen statt aus individuellem Code:

• Page-Builder-Plugins erzeugen oft deutlich mehr CSS und verschachteltes DOM als handgeschriebenes Markup
• Einzelne Plugins laden ihr JavaScript und CSS siteweit statt nur auf den Seiten, auf denen es gebraucht wird
• Consent- und Tracking-Skripte von Drittanbietern sind eine häufige INP-Ursache
• Schlecht konfigurierte Lazyload-Plugins wenden loading="lazy" pauschal auch auf das Hero-Bild an
• Ungünstig eingebundene Web Fonts verursachen Schriftwechsel-Sprünge (CLS)
• Ein langsames Hosting oder ein ungenutzter Objekt-Cache verschlechtern die TTFB und damit LCP

Die Diagnose läuft dabei genauso wie oben beschrieben: zuerst Felddaten prüfen, dann in PageSpeed Insights oder den DevTools das konkret verantwortliche Plugin, Skript oder Theme-Element identifizieren, statt pauschal ein Cache-Plugin zu installieren und auf Besserung zu hoffen.

Weiterführend

• Core Web Vitals
• WordPress
• CDN
• Cache