Core Web Vitals verbessern: LCP, INP und CLS

Ihre Website lädt in 3 Sekunden. Ist das schnell? Keine Ahnung – denn „Ladezeit” allein sagt wenig über die tatsächliche Nutzererfahrung aus. Ob ein Besucher bleibt oder abspringt, hängt von ganz konkreten Faktoren ab: Wie schnell sieht er den ersten Inhalt? Reagiert die Seite sofort auf seinen Klick? Springt das Layout beim Laden?

Genau das misst Google seit 2021 mit den Core Web Vitals – drei Metriken, die die Nutzererfahrung auf einer Website quantifizieren. Und die fließen direkt ins Ranking ein. In diesem Artikel erklären wir, was die drei Metriken messen, wie Sie sie prüfen und was Sie konkret tun können, um Ihre Website zu verbessern.

Was sind Core Web Vitals?

Core Web Vitals sind drei von Google definierte Metriken, die messen, wie sich eine Website für echte Nutzer anfühlt. Nicht wie schnell der Server antwortet oder wie groß die HTML-Datei ist – sondern was der Besucher im Browser tatsächlich erlebt.

Die drei Metriken im Überblick:

Google hat die Core Web Vitals seit 2021 als offiziellen Ranking-Faktor bestätigt. Das bedeutet: Bei zwei ansonsten gleichwertigen Websites kann die mit den besseren Core Web Vitals höher ranken.

Wichtig: Die Werte basieren nicht auf einem Labortest, sondern auf echten Nutzerdaten. Google sammelt diese über den Chrome-Browser – anonymisiert, über einen Zeitraum von 28 Tagen. Diese Felddaten bestimmen, ob Ihre Website die Core-Web-Vitals-Prüfung besteht oder nicht.

LCP – Largest Contentful Paint

LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport vollständig geladen ist. Das kann ein Hero-Bild sein, eine große Überschrift, ein Video-Thumbnail oder ein Hintergrundbild. Es ist der Moment, in dem der Besucher das Gefühl hat: „Die Seite ist da.”

Der Schwellenwert: Unter 2,5 Sekunden gilt als gut. Über 4 Sekunden als schlecht. Alles dazwischen ist verbesserungswürdig.

Häufige Ursachen für schlechtes LCP:

• Große, unkomprimierte Bilder. Ein Hero-Bild mit 2 MB statt 100 KB. PNG statt WebP. Keine responsiven Größen über srcset, sodass das Smartphone dasselbe 4K-Bild lädt wie der Desktop-Monitor.
• Langsamer Server (TTFB). Wenn der Server allein 1,5 Sekunden braucht, um zu antworten, ist ein LCP von 2,5 Sekunden kaum erreichbar. Time to First Byte ist die Basis, auf der alles andere aufbaut.
• Render-blockierendes CSS und JavaScript. Der Browser kann nichts anzeigen, solange er auf externe Stylesheets oder Skripte wartet. Jede externe CSS-Datei, jedes synchron geladene Skript verzögert den ersten sichtbaren Inhalt.
• Web Fonts ohne Fallback. Wenn die Schriftart von einem externen Server geladen wird und kein font-display: swap gesetzt ist, bleibt der Text unsichtbar (FOIT – Flash of Invisible Text), bis die Font-Datei da ist.

Was hilft: Bilder in WebP konvertieren und mit width/height ausliefern. Kritisches CSS direkt im HTML inline einbetten. Fonts lokal hosten statt von Google Fonts laden. Server-Antwortzeit durch gutes Hosting optimieren.

INP – Interaction to Next Paint

INP misst, wie schnell eine Website auf Nutzer-Interaktionen reagiert – also auf Klicks, Taps und Tastatureingaben. Der Wert gibt an, wie lange es vom Klick bis zur nächsten visuellen Reaktion dauert. Fühlt sich die Seite sofort an oder reagiert sie mit spürbarer Verzögerung?

INP hat im März 2024 den alten Messwert FID (First Input Delay) abgelöst. Der entscheidende Unterschied: FID maß nur die erste Interaktion. INP misst jede Interaktion während des gesamten Besuchs und bewertet die schlechteste. Das macht den Wert deutlich aussagekräftiger – denn eine Seite kann beim ersten Klick schnell reagieren und beim dritten einfrieren.

Der Schwellenwert: Unter 200 Millisekunden gilt als gut. Über 500 Millisekunden als schlecht.

Häufige Ursachen für schlechtes INP:

• Schweres JavaScript. Große JavaScript-Bundles blockieren den Main Thread des Browsers. Besonders betroffen: Single Page Apps mit React, Angular oder Vue, die beim Seitenaufruf erst ein komplettes Framework initialisieren müssen.
• Third-Party-Skripte. Google Analytics, Chat-Widgets, Cookie-Banner, Social-Media-Embeds – jedes externe Skript konkurriert um Rechenzeit auf dem Main Thread. Je mehr Skripte, desto träger die Seite.
• Komplexe Event-Handler. Klick-Handler, die synchron hunderte DOM-Elemente manipulieren, blockieren die Anzeige der nächsten visuellen Änderung.

Was hilft: JavaScript aufteilen (Code Splitting), Third-Party-Skripte verzögert laden oder ganz eliminieren, lange Aufgaben in kleinere Teilaufgaben aufbrechen.

CLS – Cumulative Layout Shift

CLS misst, wie stark sich sichtbare Elemente beim Laden einer Seite verschieben. Es ist die Metrik, die das frustrierendste Nutzererlebnis im Web quantifiziert: Sie wollen auf einen Button klicken, aber im letzten Moment rutscht alles nach unten – und Sie treffen statt dem Button eine Werbeanzeige.

Der Schwellenwert: Unter 0,1 gilt als gut. Über 0,25 als schlecht.

Häufige Ursachen für schlechtes CLS:

• Bilder ohne Größenangaben. Ohne width und height im HTML-Tag weiß der Browser nicht, wie viel Platz er reservieren soll. Das Bild lädt nach, springt in den Viewport und verschiebt alles darunter.
• Nachladende Web Fonts. Wenn der Web Font andere Buchstabenbreiten hat als der System-Fallback-Font, verschiebt sich beim Font-Wechsel der gesamte Text – Zeilen werden länger oder kürzer, Absätze wandern.
• Dynamisch eingefügte Inhalte. Cookie-Banner, die sich von oben ins Layout schieben. Newsletter-Popups. Nachladende Werbebanner. Alles, was nach dem initialen Rendering erscheint und andere Elemente verdrängt.

Bilder ohne width und height sind die häufigste CLS-Ursache auf Firmenwebsites – und gleichzeitig die einfachste zu beheben. Zwei HTML-Attribute pro Bild, und das Problem ist gelöst.

Was hilft: Auf jedem <img>-Tag immer width und height angeben. Fonts lokal hosten mit font-display: swap, damit der Fallback-Font sofort angezeigt wird. Für dynamische Inhalte wie Cookie-Banner feste Platzhalter im Layout reservieren – oder besser: ganz darauf verzichten.

Core Web Vitals messen: Die wichtigsten Tools

Sie müssen kein Entwickler sein, um Ihre Core Web Vitals zu prüfen. Google stellt mehrere kostenlose Tools bereit, die den aktuellen Status Ihrer Website zeigen.

PageSpeed Insights. Das wichtigste Tool für den Einstieg. URL eingeben unter pagespeed.web.dev, Ergebnis in Sekunden. PageSpeed Insights zeigt sowohl Lab-Daten (simulierter Test) als auch Field-Daten (echte Nutzerdaten aus dem Chrome UX Report). Für die Bewertung Ihrer Core Web Vitals zählen die Field-Daten.

Google Search Console. Unter „Nutzerfreundlichkeit” → „Core Web Vitals” sehen Sie den Status aller URLs Ihrer Website – gruppiert nach „gut”, „verbesserungswürdig” und „schlecht”. Ideal, um Problemseiten zu identifizieren und die Entwicklung über Wochen zu verfolgen.

Chrome DevTools (Lighthouse). F12 drücken → Lighthouse-Tab → Performance-Audit starten. Gut für die Entwicklung und Diagnose, aber: Lighthouse liefert nur Lab-Daten – keine echten Nutzerdaten. Die Werte können von den Field-Daten abweichen.

web.dev/measure. Ähnlich wie PageSpeed Insights, zusätzlich mit Accessibility- und Best-Practices-Checks. Nützlich als Ergänzung, aber kein Muss.

PageSpeed Score vs. Core Web Vitals

Das häufigste Missverständnis bei der Performance-Optimierung: „Mein PageSpeed Score ist 95 – also sind meine Core Web Vitals in Ordnung.” Das stimmt nicht unbedingt. Score und Core Web Vitals messen unterschiedliche Dinge.

Der PageSpeed Score ist ein synthetischer Wert. Er basiert auf einem Lab-Test – einer Simulation auf einem gedrosselten Gerät unter standardisierten Bedingungen. Wie ein TÜV-Test auf dem Prüfstand: kontrollierte Umgebung, reproduzierbare Ergebnisse, aber nicht zwingend das, was im Straßenverkehr passiert.

Core Web Vitals dagegen basieren auf Field-Daten – echten Nutzerdaten aus dem Chrome-Browser, gesammelt über 28 Tage. Wie sich Ihre Website tatsächlich anfühlt, auf echten Geräten, mit echten Internetverbindungen.

Was Google als Ranking-Signal nutzt: Die Field-Daten. Nicht den Score.

Das bedeutet: Eine Website mit PageSpeed Score 95 kann durchaus schlechte Core Web Vitals haben – etwa weil die echten Nutzer überwiegend auf langsamen Mobilgeräten surfen. Umgekehrt kann eine Website mit Score 70 in der Praxis gut performen, wenn die echten Nutzerdaten stimmen.

Der Score bleibt trotzdem nützlich – als Diagnose-Tool. Er zeigt, wo Optimierungspotenzial liegt. Aber verwechseln Sie ihn nicht mit der Bewertung Ihrer Core Web Vitals. Die beiden sind nicht dasselbe.

Häufige Fehler bei der Performance-Optimierung

In unserer Arbeit mit Kunden-Websites sehen wir immer wieder dieselben Muster:

• Score-Jagd statt Nutzererfahrung. Stundenlang von Score 92 auf 97 optimieren, während die echten Nutzer gar kein Problem haben. Der Score ist ein Richtwert, kein Wettbewerb. Wenn Ihre Field-Daten im grünen Bereich sind, ist der Score zweitrangig.
• Bilder nicht optimiert. PNG statt WebP, keine responsiven Größen über srcset, kein Lazy Loading für Bilder unterhalb des sichtbaren Bereichs. Bilder sind auf den meisten Websites der größte Performance-Faktor – und der einfachste zu optimieren.
• Zu viele Third-Party-Skripte. Google Analytics, Tag Manager, Hotjar, Chat-Widget, Cookie-Banner – jedes Skript kostet Ladezeit, Main-Thread-Zeit und oft auch CLS. Die Frage ist nicht „Was noch installieren?”, sondern „Was davon brauchen wir wirklich?”
• Google Fonts extern laden. Jeder Google-Fonts-Aufruf bedeutet einen zusätzlichen DNS-Lookup, eine TCP-Verbindung und einen HTTP-Request zu Googles Servern. Fonts lokal zu hosten ist schneller, zuverlässiger und DSGVO-konform.
• Kein Caching für statische Assets. Bilder, CSS und JavaScript ohne Cache-Header ausliefern bedeutet: Bei jedem Seitenaufruf wird alles neu heruntergeladen. Ein einfacher Cache-Header spart Ihren Besuchern bei wiederholten Besuchen Sekunden.

Fazit: Nutzererfahrung schlägt Score

Core Web Vitals messen, wie sich Ihre Website für echte Besucher anfühlt – nicht wie schnell ein Score-Tool sie in einer Laborsimulation bewertet. Drei Metriken entscheiden: LCP (wie schnell sieht man Inhalt), INP (wie schnell reagiert die Seite) und CLS (bleibt das Layout stabil).

Einmal optimiert, profitieren Sie bei jedem einzelnen Seitenaufruf: weniger Absprünge, bessere Rankings, zufriedenere Besucher. Und das Beste: Die meisten Verbesserungen – Bilder optimieren, Fonts lokal hosten, unnötige Skripte entfernen – kosten nichts außer einmaligem Aufwand.

Wenn Sie unsicher sind, wie Ihre Website bei den Core Web Vitals abschneidet: PageSpeed Insights aufrufen, URL eingeben und auf die Felddaten schauen. Das dauert 30 Sekunden – und zeigt Ihnen sofort, wo Sie stehen.