Core Web Vitals: LCP, INP und CLS erklaert

Core Web Vitals sind die Brueckenmetriken zwischen technischem SEO und tatsaechlicher Nutzererfahrung. Sie uebersetzen abstrakte Performance-Begriffe in drei messbare Werte, die Google direkt aus den Browsern echter Besucher erhebt. Dieser Artikel erklaert LCP, INP und CLS im Detail, ordnet ihr realistisches Gewicht als Ranking-Signal ein und zeigt, wie sich die Metriken in einem modernen Stack aus Next.js, Edge/CDN und HTTP/3 gezielt verbessern lassen. Der Fokus liegt auf dem DACH-Raum mit seiner ausgepraegten Mobil-Dominanz.

Warum Core Web Vitals fuer technisches SEO zaehlen

Core Web Vitals sind der Teil der Page Experience, den Google nicht nur predigt, sondern auch in den Ranking-Systemen verwendet. In der offiziellen Dokumentation stellt Google klar, dass es kein einzelnes Page-Experience-Signal gibt, dass die Core Web Vitals aber von den Ranking-Systemen genutzt werden und eine gute Page Experience bei Suchanfragen mit viel hilfreichem Content zum Sucherfolg beitragen kann (Google Search Central). Damit sind die drei Metriken kein Ranking-Hauptfaktor, aber ein belastbares Qualitaetssignal, das vor allem dann den Ausschlag gibt, wenn mehrere inhaltlich gleichwertige Ergebnisse konkurrieren.

Die Praxis zeigt, wie viel Luft nach oben besteht. Laut dem Web Almanac 2024 bestehen nur 43 Prozent der mobilen Origins alle drei Core Web Vitals, auf dem Desktop sind es 54 Prozent (HTTP Archive, Web Almanac 2024). Wer hier sauber arbeitet, hebt sich also von mehr als der Haelfte des mobilen Webs ab. Fuer Oesterreich ist das besonders relevant, weil die Internetnutzung stark mobil gepraegt ist: Im Juni 2024 erfolgten 81,5 Prozent der Internetzugriffe in Oesterreich ueber mobile Endgeraete, davon 31,6 Prozent ueber das mobile Web (Statista, Oesterreichische Webanalyse). Mobil-Performance ist im DACH-Markt damit kein Nebenschauplatz, sondern der Normalfall, an dem CWV bestanden oder verfehlt werden.

Die drei Metriken und ihre Schwellenwerte

Google segmentiert die Bewertung in good, needs improvement und poor und misst stets am 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop. Die offiziellen good-Schwellenwerte lauten: LCP unter 2,5 Sekunden, INP von 200 Millisekunden oder weniger und CLS von 0,1 oder weniger (web.dev). Das 75. Perzentil bedeutet konkret: Drei von vier Aufrufen muessen den Schwellenwert erreichen, der schlechteste Viertel zaehlt nicht. Eine Seite besteht ein Core Web Vital also erst, wenn sie zuverlaessig schnell ist, nicht nur im Idealfall.

• Largest Contentful Paint (LCP): misst, wann das groesste sichtbare Element im Viewport gerendert ist. Es ist der Stellvertreter fuer die gefuehlte Ladegeschwindigkeit.
• Interaction to Next Paint (INP): misst die Latenz zwischen einer Nutzerinteraktion und der naechsten sichtbaren Bildaktualisierung, ueber die gesamte Sitzung hinweg.
• Cumulative Layout Shift (CLS): misst die Summe unerwarteter Layout-Verschiebungen, also wie stabil der Inhalt waehrend des Ladens bleibt.

Auf Einzelmetrik-Ebene ist das Bild im DACH-relevanten Mobilsegment uneinheitlich. 2024 erreichten 59 Prozent der mobilen Seiten ein gutes LCP, 74 Prozent ein gutes INP und 79 Prozent ein gutes CLS (Web Almanac 2024). LCP ist damit auf Mobilgeraeten die am haeufigsten verfehlte der drei Metriken.

LCP im Detail: Ladewahrnehmung optimieren

Bei LCP geht es fast immer um ein Bild. 73,3 Prozent der mobilen Seiten haben ein Bild als LCP-Element (Web Almanac 2024). Das LCP-Bild ist damit der wichtigste einzelne Optimierungshebel. Die typischen Ursachen fuer langsames LCP liegen in drei Bereichen: einer hohen Server-Antwortzeit (TTFB), render-blockierenden Ressourcen wie CSS und JavaScript im kritischen Pfad sowie der reinen Ladezeit der LCP-Ressource selbst.

Die wirksamsten Gegenmassnahmen setzen genau dort an:

• Prioritaet steuern: Das LCP-Bild mit fetchpriority="high" auszeichnen und gegebenenfalls per <link rel="preload"> frueh anfordern, damit der Browser es nicht hinter weniger wichtigen Ressourcen einreiht.
• Niemals das LCP-Bild lazy-laden: Ein verbreitetes Anti-Pattern. 16 Prozent der mobilen Seiten lazy-laden ihr LCP-Bild, 9,5 Prozent sogar ueber das native loading="lazy" (Web Almanac 2024). Das LCP-Element gehoert ueber dem Falz und muss eager geladen werden.
• Moderne Bildformate nutzen: AVIF und WebP reduzieren die Dateigroesse gegenueber JPEG deutlich und verkuerzen so die Ressourcen-Ladezeit.
• TTFB ueber Edge/CDN senken: Auslieferung aus einem CDN-Knoten nahe am Nutzer und moderne Transportprotokolle verkuerzen die Server-Antwortzeit, bevor ueberhaupt ein Pixel gerendert wird.

INP im Detail: Interaktivitaet sicherstellen

INP hat FID am 12. Maerz 2024 als Core Web Vital abgeloest und wurde gleichzeitig in der Search Console anstelle von FID gefuehrt (web.dev). Der Wechsel war kein kosmetischer: FID mass nur die Verzoegerung der ersten Interaktion, INP bewertet alle Interaktionen einer Sitzung und ist deutlich strenger. Genau das schlaegt sich in den Zahlen nieder: Mit FID haetten 2024 noch 48 Prozent der mobilen Seiten gute CWV gehabt, mit INP sind es nur 43 Prozent (Web Almanac 2024).

INP setzt sich aus drei Phasen zusammen: dem Input Delay (Wartezeit, bis der Event-Handler starten kann), der Processing Time (Ausfuehrung des Handlers) und dem Presentation Delay (Zeit bis zum naechsten Frame). Die mit Abstand haeufigste Ursache fuer schlechtes INP ist blockierendes JavaScript, das den Main Thread belegt und Interaktionen aufstaut. Die Optimierung folgt daraus:

• Lange Tasks aufteilen (Task Splitting): Grosse JavaScript-Aufgaben in kleinere Stuecke zerlegen und dem Browser zwischendurch die Kontrolle zurueckgeben, etwa per scheduler.yield() oder Aufschub, damit Eingaben nicht warten muessen.
• Ereignisse entkoppeln (Debouncing): Haeufig feuernde Handler wie Scroll- oder Input-Events drosseln, damit nicht bei jedem Pixel teure Logik laeuft.
• Arbeit auslagern (Web Workers): Rechenintensive, nicht-UI-bezogene Arbeit in einen Web Worker verschieben, um den Main Thread frei zu halten.

CLS im Detail: visuelle Stabilitaet halten

CLS bestraft Inhalte, die nach dem ersten Rendern noch springen. Die Ursachen sind gut bekannt: Bilder und Iframes ohne feste Dimensionen, dynamisch nachgeladener Content ueber bestehendem Inhalt, spaet ladende Web Fonts mit Layout-Sprung sowie Werbeflaechen ohne reservierten Platz. Die Gegenmassnahmen sind durchgaengig praeventiv:

• Dimensionen vorgeben: Fuer Bilder und Videos immer width und height oder eine aspect-ratio setzen, damit der Browser den Platz vor dem Laden reserviert.
• Platz fuer dynamische Elemente reservieren: Fuer Ads, Embeds und nachgeladene Banner feste Slots im Layout vorsehen, statt sie in den Fluss einzuschieben.
• Schriftwechsel entschaerfen: Mit font-display und vorab geladenen Schriften das Umfliessen beim Font-Tausch minimieren.

Mit 79 Prozent guter Werte auf Mobilgeraeten ist CLS die am besten beherrschte der drei Metriken (Web Almanac 2024). Das liegt daran, dass die Gegenmassnahmen technisch einfach und einmalig umsetzbar sind.

Best Practices: CWV im Next.js- und Edge-Stack

In Next.js sind viele CWV-Optimierungen bereits in den Framework-Bausteinen angelegt, muessen aber bewusst genutzt werden. next/image erzwingt Dimensionen, liefert moderne Formate aus und setzt fuer das wichtigste Bild ueber das priority-Attribut automatisch fetchpriority="high", was direkt auf LCP einzahlt. next/font laedt Schriften lokal und selbst-gehostet und vermeidet so den Font-bedingten Layout-Sprung, der CLS verschlechtert. Streaming via SSR und React Server Components reduziert das an den Client gesendete JavaScript, was die Hauptursache von INP entschaerft.

Die kritischste Stelle im App Router ist die Hydration. Jede interaktive Client-Komponente muss im Browser hydriert werden, und zu viel Client-JavaScript erzeugt genau die langen Tasks, die INP nach oben treiben. Praktisch heisst das: so viel wie moeglich als Server Component belassen, Interaktivitaet auf kleine Client-Inseln begrenzen und schwere Komponenten gezielt nachladen.

Der technische Unterbau verstaerkt diese Effekte. Im Web werden inzwischen 54 Prozent von ueber 1,3 Milliarden Requests ueber ein CDN ausgeliefert, waehrend HTTP/3 zwar bei rund 30 Prozent der Seiten verfuegbar ist, aber nur bei 7 bis 9 Prozent der ersten Seitenaufrufe tatsaechlich genutzt wird (Web Almanac 2024, HTTP). Edge-Caching und HTTP/3 senken TTFB und damit den Startpunkt von LCP, ohne dass am Frontend-Code etwas geaendert werden muss. Schnellere, sauber gecachte Auslieferung kommt zudem dem Crawl-Budget und KI-Crawlern zugute, die das Web in wachsendem Umfang abrufen: Googlebot stieg von Mai 2024 bis Mai 2025 um 96 Prozent und haelt rund 50 Prozent Crawler-Anteil, GPTBot legte von 2,2 auf 7,7 Prozent zu (Cloudflare). Eine performante, vorhersagbar ausgelieferte Seite ist somit auch fuer Generative Engine Optimization (GEO) ein Vorteil.

Haeufige Fehler bei der CWV-Optimierung

• Lab-Werte fuer die Realitaet halten: Ein gruener Lighthouse-Score im Labor sagt nichts ueber das aus, was Google wertet. Massgeblich ist das 75. Perzentil echter Nutzer.
• Das LCP-Bild lazy-laden: Der haeufigste Selbstschaden bei LCP. Das Element ueber dem Falz darf nie verzoegert geladen werden.
• INP mit FID verwechseln: Wer noch nach FID optimiert, misst die falsche Groesse. INP ist seit Maerz 2024 die einzige relevante Interaktivitaetsmetrik.
• CLS nur am Seitenanfang pruefen: Layout-Sprung passiert oft erst beim Scrollen oder bei spaeten Einschueben. CLS wird ueber den gesamten Lebenszyklus der Seite gemessen.
• Nur den Desktop testen: Im DACH-Raum entscheidet die mobile Realitaet. Tests muessen mobil mit gedrosselter CPU und Netzwerk erfolgen.

Messung: Lab vs. Field und die richtigen Tools

Die wichtigste Unterscheidung ist die zwischen Labor- und Felddaten. Labordaten (Lab) entstehen in einer kontrollierten Umgebung, etwa in Lighthouse, und eignen sich zum Debuggen und fuer reproduzierbare Vergleiche. Sie fliessen aber nicht ins Ranking ein. Felddaten (Field) stammen von echten Nutzern und werden im 75. Perzentil ausgewertet (web.dev). Nur diese Real-User-Daten zaehlen fuer die Bewertung.

• Chrome UX Report (CrUX): Die offizielle Feld-Datenquelle, aggregiert aus realen Chrome-Nutzern. Basis fuer den Search-Console-Bericht und PageSpeed Insights.
• PageSpeed Insights: Kombiniert CrUX-Felddaten oben mit einem Lighthouse-Lab-Lauf darunter. Ideal, um den realen Status und die technische Ursache nebeneinander zu sehen.
• Search Console CWV-Bericht: Gruppiert URLs nach good, needs improvement und poor auf Feldbasis und zeigt die Entwicklung ueber die Zeit fuer die gesamte Property.
• RUM und web-vitals.js: Eigene Real-User-Messung im Code, etwa ueber die Bibliothek web-vitals.js, liefert kontinuierliche Felddaten und granulare Diagnose, auch fuer Tools wie DebugBear.

Wer Lab und Field konsequent trennt, vermeidet den haeufigsten Interpretationsfehler: ein gutes Laborergebnis als bestandenes Core Web Vital zu deuten.

CWV als Ranking-Signal und der Business-Case

Die realistische Erwartung lautet: Core Web Vitals ersetzen weder Relevanz noch hochwertigen Content. Google formuliert ausdruecklich, dass es kein einzelnes Signal gibt und stets die relevanteste Antwort zeigen will, auch bei suboptimaler Page Experience, eine gute Page Experience aber bei Suchanfragen mit viel hilfreichem Content den Unterschied machen kann (Google Search Central). CWV wirken damit als Verstaerker und Tie-Breaker, nicht als Abkuerzung an schwachem Inhalt vorbei.

Der staerkere Hebel ist oft die Conversion. Die von Google dokumentierte Fallstudie zu redBus zeigt, dass eine gezielte INP-Optimierung den Umsatz um 7 Prozent steigerte, wobei INP selbst um 72 Prozent verbessert wurde, unter anderem durch debounced Scroll-Handler und reduzierte API-Abfragen (web.dev, redBus). Diese Zahlen stammen aus einem internationalen Fall, der Mechanismus ist aber uebertragbar: schnellere Interaktionen senken Abbrueche und erhoehen den Abschluss. Im oesterreichischen Kontext, wo 81,5 Prozent der Zugriffe mobil erfolgen (Statista), trifft jede mobile INP- oder LCP-Verbesserung direkt den groessten Teil der Besucher. Der Business-Case fuer CWV ist deshalb weniger ein SEO-Argument als ein Umsatz-Argument mit SEO-Nebeneffekt.

Weiterfuehrendes

Core Web Vitals sind am wirksamsten, wenn sie in den gesamten technischen SEO-Stack eingebettet werden. LCP haengt an TTFB und damit an Edge/CDN-Caching und HTTP/3, INP an der JavaScript- und Rendering-Strategie, und alle drei profitieren von einer sauberen Next.js-Architektur mit minimalem Client-JavaScript. Wer hier investiert, verbessert gleichzeitig die Auslieferung an klassische Crawler wie an KI-Crawler und damit die GEO-Sichtbarkeit. Vertiefen laesst sich das Thema in den verwandten Artikeln zu Rendering und JavaScript-SEO, HTTP/3 und Edge/CDN sowie zur Next.js-SEO-Architektur.