Core Web Vitals verstehen, messen und gezielt verbessern

Core Web Vitals sind die drei nutzerzentrierten Kennzahlen, die Google für die Bewertung der Seitenqualität heranzieht: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Eine Seite gilt laut Google Search Central als „gut“, wenn mindestens 75 % der echten Seitenaufrufe diese Werte erreichen: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1. Entscheidend sind dabei keine Laborwerte, sondern Felddaten aus dem Chrome User Experience Report (CrUX). Prüfen Sie jetzt Ihre Google Search Console: Der Core Web Vitals Report zeigt Ihnen sofort, welche URLs als „schlecht“ oder „verbesserungswürdig“ eingestuft sind.

Drei Punkte, die Sie direkt mitnehmen können:

LCP misst, wann das größte sichtbare Element geladen ist. Ziel: ≤ 2,5 s.
INP misst die Reaktionszeit auf Nutzereingaben. Ziel: ≤ 200 ms.
CLS misst unerwartete Layoutverschiebungen. Ziel: ≤ 0,1.

Alle drei Metriken werden am 75. Perzentil Ihrer Besucher gemessen.

Wichtige Erkenntnisse

Core Web Vitals (LCP, INP, CLS) entscheiden am 75. Perzentil der echten Nutzer darüber, ob Google eine Seite als „gut“ einstuft, und beeinflussen damit Ranking und Nutzererfahrung gleichermaßen.

Thema	Details
Drei Metriken, klare Ziele	LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 gelten am 75. Perzentil als „gut“.
Felddaten entscheiden	CrUX-Daten in der Search Console sind Googles Bewertungsgrundlage, nicht Laborwerte.
Häufigste Quick-Wins	Hero-Bild als `<img>` mit Preload, Bildabmessungen festlegen, unnötige Scripts entfernen.
Mobil hat Vorrang	Google bewertet Mobil und Desktop getrennt; der Mobilwert ist für das Ranking relevanter.
Einfach-sichtbar	Unterstützt KMU in der Bodenseeregion mit Audit, Umsetzung und Monitoring vor oder nach einem Relaunch.

Inhaltsverzeichnis

Was sind Core Web Vitals? LCP, INP und CLS im Überblick
Warum Core Web Vitals für Ihr Ranking und Ihre Nutzer wichtig sind
Wie Google tatsächlich misst: Felddaten, CrUX und das 75. Perzentil
Welche Tools helfen Ihnen beim Messen und Diagnostizieren?
Wie Sie die Ursachen für schlechten LCP, INP und CLS finden
Konkrete Maßnahmen für LCP, INP und CLS
Monitoring aufbauen: KPIs, RUM und synthetische Tests
Praxis-Checkliste für KMU: Schnelle Wins und wann externe Hilfe sinnvoll ist
Was die Praxis wirklich lehrt
Wie Einfach-sichtbar beim Messen und Verbessern unterstützt
Quellen

Was sind Core Web Vitals? LCP, INP und CLS im Überblick

Largest Contentful Paint (LCP)

LCP misst, wie lange es dauert, bis das größte sichtbare Inhaltselement im Viewport gerendert ist. Typische LCP-Elemente sind Hero-Bilder, große Textblöcke oder Video-Thumbnails. Laut Web lässt sich LCP in vier Teilabschnitte zerlegen: Time to First Byte (TTFB), Resource Load Delay, Resource Load Time und Element Render Delay. Wer LCP verbessern will, muss wissen, welcher dieser vier Abschnitte der Engpass ist.

Interaction to Next Paint (INP)

INP ersetzt seit März 2024 den alten First Input Delay (FID) als offiziellen Core Web Vital. Die Metrik erfasst die Latenz aller Klick-, Tipp- und Tastatureingaben während eines Seitenbesuchs und gibt den schlechtesten Wert (mit leichter Glättung) zurück. Ein INP über 500 ms ist ein klares Signal für blockierendes JavaScript.

Cumulative Layout Shift (CLS)

CLS bewertet, wie stark sich Seitenelemente während des Ladens unerwartet verschieben. Die Berechnung folgt der Formel Impact Fraction × Distance Fraction, wobei Google Session-Windows von maximal 5 Sekunden verwendet und den höchsten Fensterwert als finalen CLS-Score nimmt. Bilder und Iframes ohne definierte Abmessungen sind laut MetricSpot die häufigsten Verursacher.

Schwellenwerte und das 75. Perzentil

Metrik	Gut	Verbesserungswürdig	Schlecht
LCP	≤ 2,5 s	2,5 s – 4,0 s	> 4,0 s
INP	≤ 200 ms	200 ms – 500 ms	> 500 ms
CLS	≤ 0,1	≤ 0,1	> 0,1

Die Schwellenwerte wurden anhand von CrUX-Daten so gewählt, dass sie für die meisten Websites erreichbar sind, wie web.dev erklärt. Das 75. Perzentil als Messbasis stellt sicher, dass auch langsame Verbindungen und ältere Geräte in die Bewertung einfließen, nicht nur die schnellsten Nutzer.

Mobil vs. Desktop: Google bewertet beide Plattformen getrennt. Eine Seite kann auf dem Desktop „gut“ sein und auf Mobilgeräten gleichzeitig „schlecht“. Da Google primär den mobilen Index bewertet, hat der Mobilwert in der Praxis mehr Gewicht. Wer Mobile-First-Design konsequent umsetzt, hat hier einen strukturellen Vorteil.

Warum Core Web Vitals für Ihr Ranking und Ihre Nutzer wichtig sind

Core Web Vitals sind keine rein technischen Kennzahlen. Sie bilden ab, was Nutzer tatsächlich wahrnehmen: Lädt die Seite schnell? Reagiert sie auf Eingaben? Springt der Inhalt beim Laden herum? Web.dev beschreibt sie explizit als UX-Signale, die echte Nutzerzufriedenheit messen sollen.

Für SEO gilt: Google nutzt Page Experience, zu der Core Web Vitals gehören, als Tiebreaker bei ähnlicher inhaltlicher Relevanz. Zwei Seiten mit vergleichbarem Content können sich im Ranking unterscheiden, wenn eine deutlich bessere Nutzererfahrung bietet. Das ist kein Geheimnis, aber viele Webseitenbetreiber unterschätzen den kumulativen Effekt.

Konkret wirken sich schlechte Werte auf folgende Bereiche aus:

Absprungrate: Langsame Seiten verlieren Besucher, bevor der eigentliche Inhalt sichtbar wird.
Conversion: Layoutverschiebungen führen zu Fehlklicks, etwa auf falsche Buttons.
Crawl-Effizienz: Sehr langsame Seiten werden seltener vollständig gecrawlt.

Gut: Core Web Vitals sind messbar und gezielt verbesserbar. Das macht sie zu einem der wenigen SEO-Faktoren, bei dem technische Arbeit direkt in Rankings und Nutzererfahrung übersetzt werden kann.

Wie Google tatsächlich misst: Felddaten, CrUX und das 75. Perzentil

Felddaten vs. Labordaten

Der entscheidende Unterschied: Felddaten stammen von echten Chrome-Nutzern und fließen über CrUX in die offizielle Google-Bewertung ein. Labordaten werden in einer kontrollierten Umgebung simuliert, zum Beispiel durch Lighthouse oder PageSpeed Insights. Labordaten sind unverzichtbar für die Fehlersuche, aber sie entscheiden nicht über Ihr Ranking.

Der Core Web Vitals Report in der Search Console basiert ausschließlich auf CrUX-Felddaten der letzten 28 Tage. Google gruppiert dabei URLs mit ähnlichem Verhalten, sodass auch Seiten mit wenig Traffic bewertet werden können, wenn ähnliche URLs genug Daten liefern.

Datentyp	Quelle	Verwendung
Felddaten (CrUX)	Echte Chrome-Nutzer	Offizielle Google-Bewertung, Search Console
Labordaten	Lighthouse, simuliertes Gerät	Debugging, Diagnose, Entwicklung

Das 75. Perzentil in der Praxis

Stellen Sie sich vor, 100 Nutzer besuchen Ihre Seite. Google sortiert deren LCP-Werte von schnell nach langsam und schaut auf Platz 75. Liegt dieser Wert über 4,0 s, gilt die Seite als „schlecht“, unabhängig davon, wie gut die anderen 74 Nutzer abgeschnitten haben. Das Prinzip schützt vor Schönrechnerei durch Durchschnittswerte.

Profi-Tipp: Wenn Ihre Search Console wenig Felddaten anzeigt (häufig bei neuen oder wenig besuchten Seiten), nutzen Sie PageSpeed Insights für eine Kombination aus verfügbaren CrUX-Daten und Lighthouse-Labordaten. Für Seiten ohne ausreichende CrUX-Datenbasis fehlt der offizielle Status in der Search Console.

Welche Tools helfen Ihnen beim Messen und Diagnostizieren?

Jedes Tool hat seinen eigenen Einsatzbereich. Die Kombination macht den Unterschied.

Google Search Console (Core Web Vitals Report)

Der Ausgangspunkt für jeden Audit. Der Report zeigt, welche URL-Gruppen als „gut“, „verbesserungswürdig“ oder „schlecht“ eingestuft sind, getrennt nach Mobil und Desktop. Er basiert auf CrUX-Felddaten und ist damit die einzige Ansicht, die direkt Googles Bewertungsgrundlage widerspiegelt. Schwäche: Er zeigt keine Ursachen, nur Symptome.

PageSpeed Insights

PageSpeed Insights kombiniert CrUX-Felddaten mit Lighthouse-Labordaten in einer einzigen Ansicht. Ideal als erster Diagnoseschritt nach der Search Console.

Lighthouse

Lighthouse läuft direkt in Chrome DevTools oder als CLI-Tool und liefert detaillierte Laborberichte mit Optimierungshinweisen. Besonders nützlich während der Entwicklung, weil Änderungen sofort testbar sind, ohne auf CrUX-Daten warten zu müssen. Lighthouse simuliert ein gedrosseltes Mobilnetz und ein Mittelklasse-Gerät.

Chrome DevTools

DevTools bieten die tiefste Diagnoseebene. Im Performance-Panel sehen Sie Long Tasks, JavaScript-Ausführungszeiten und den genauen Zeitpunkt von Layoutverschiebungen. Im Rendering-Panel lassen sich Layout-Shift-Bereiche farblich hervorheben. Für CLS-Debugging ist das unverzichtbar.

WebPageTest

WebPageTest ermöglicht Tests von echten Geräten und Standorten weltweit, inklusive Waterfall-Ansicht aller Ressourcen. Besonders hilfreich, wenn Sie wissen wollen, wie Ihre Seite auf einem deutschen Mobilnetz lädt, nicht auf einem US-amerikanischen Testserver.

web-vitals JavaScript Library

Die web-vitals Library von Google ermöglicht Real User Monitoring (RUM) direkt im Browser. Sie misst LCP, INP und CLS bei echten Nutzern und kann die Werte an Analytics-Systeme wie Google Analytics 4 oder ein eigenes Dashboard senden. Damit bauen Sie ein kontinuierliches Monitoring auf, das unabhängig von CrUX-Verzögerungen funktioniert.

WebPageTest als Ergänzung

Für komplexe Diagnosen, etwa wenn ein Drittanbieter-Script den INP blockiert, liefert WebPageTest Waterfall-Daten, die zeigen, welche Ressource wann geladen wird und was andere Ressourcen blockiert.

Wie Sie die Ursachen für schlechten LCP, INP und CLS finden

1. LCP-Element identifizieren

Öffnen Sie PageSpeed Insights für Ihre URL. Im Abschnitt „Diagnose“ zeigt das Tool das LCP-Element direkt an. Alternativ: Chrome DevTools öffnen, Performance-Aufzeichnung starten, Seite neu laden und im Flame-Chart nach dem LCP-Marker suchen. Das Element ist meist ein Hero-Bild oder ein großer Textblock.

2. LCP-Subparts analysieren

Sobald das Element bekannt ist, prüfen Sie die vier Subparts: TTFB, Resource Load Delay, Resource Load Time und Element Render Delay. Ein hoher TTFB deutet auf Serverprobleme hin. Ein langer Resource Load Delay bedeutet, dass der Browser das Bild zu spät entdeckt. Preload-Tags lösen dieses Problem direkt.

3. CLS-Verursacher aufspüren

In Chrome DevTools unter „Rendering“ die Option „Layout Shift Regions“ aktivieren. Dann die Seite langsam laden, idealerweise mit gedrosseltem Netzwerk. Verschobene Bereiche werden rot markiert. Häufige Ursachen: Bilder ohne width– und height-Attribut, nachträglich eingefügte Werbebanner, Schriften, die nach dem Laden wechseln.

4. INP-Probleme lokalisieren

Im Performance-Panel von DevTools nach „Long Tasks“ suchen, also Aufgaben, die länger als 50 ms dauern. Drittanbieter-Scripts wie Chat-Widgets oder Tag-Manager sind oft die Hauptverursacher. Das Performance-Panel zeigt, welches Script wann ausgeführt wird.

Profi-Tipp: Testen Sie CLS immer mit gedrosseltem Netzwerk (z. B. „Slow 4G“ in DevTools). Auf schnellen Verbindungen laden Ressourcen so schnell, dass Verschiebungen unsichtbar bleiben, obwohl sie für Nutzer mit schlechterem Netz deutlich auftreten.

Troubleshooting-Checkliste nach Priorität

Server und TTFB: Hosting-Qualität prüfen, Caching aktivieren, CDN einsetzen.
Render-Blocking-Ressourcen: CSS und JavaScript, die den ersten Paint verzögern, identifizieren und verschieben.
Bildressourcen: Formate, Größen und Preload-Strategie prüfen.
Drittanbieter-Scripts: Welche Scripts laden synchron? Können sie verzögert oder asynchron geladen werden?
Layoutverschiebungen: Alle Bilder, Iframes und dynamisch eingefügten Elemente auf feste Abmessungen prüfen.

Konkrete Maßnahmen für LCP, INP und CLS

LCP verbessern

Das Hero-Bild ist in den meisten Websites das LCP-Element. Moderne Bildformate wie WebP oder AVIF reduzieren die Dateigröße deutlich, ohne sichtbaren Qualitätsverlust. Dazu kommen:

<link rel="preload" as="image"> für das Hero-Bild, damit der Browser es früh entdeckt.
Kein loading="lazy" auf dem LCP-Element, da Lazy Loading den Ladestart verzögert.
Kritisches CSS inline einbetten, damit der Browser nicht auf eine externe CSS-Datei warten muss.
TTFB unter 800 ms halten: schnelles Hosting, serverseitiges Caching und ein CDN sind die wirksamsten Hebel.

Profi-Tipp: Prüfen Sie mit PageSpeed Insights, ob Ihr LCP-Bild mit fetchpriority="high" ausgezeichnet ist. Dieses Attribut signalisiert dem Browser, das Bild vor anderen Ressourcen zu laden, ohne einen separaten Preload-Tag zu benötigen.

INP verbessern

Blockierendes JavaScript ist der häufigste INP-Killer. Maßnahmen:

Long Tasks aufteilen: Aufgaben, die länger als 50 ms dauern, in kleinere Einheiten zerlegen, zum Beispiel mit setTimeout oder scheduler.yield().
Event-Handler mit Debounce oder Throttle versehen, damit Scroll- und Eingabe-Events nicht bei jedem Pixel feuern.
Code-Splitting einsetzen: Nur das JavaScript laden, das für die aktuelle Seite gebraucht wird.
Drittanbieter-Scripts (Tag Manager, Chat, Social Plugins) auf Notwendigkeit prüfen und verzögert laden.

CLS beheben

Feste Abmessungen für alle Bilder und Iframes sind die wichtigste Einzelmaßnahme. Das aspect-ratio-CSS-Attribut ist eine moderne Alternative zu festen Pixelwerten. Weitere Punkte:

Werbebanner und Cookie-Banner: Platz reservieren, bevor der Inhalt erscheint, nicht danach.
Schriften: font-display: optional oder font-display: swap mit passenden Fallback-Metriken verwenden, damit kein Layout-Shift durch Schriftwechsel entsteht.
Dynamisch eingefügte Inhalte (z. B. Benachrichtigungen) immer unterhalb des sichtbaren Bereichs einfügen.

Monitoring aufbauen: KPIs, RUM und synthetische Tests

Konkrete KPI-Ziele

Setzen Sie sich klare Zielwerte, getrennt nach Mobil und Desktop:

LCP ≤ 2,5 s am 75. Perzentil
INP ≤ 200 ms am 75. Perzentil
CLS ≤ 0,1 am 75. Perzentil

Wer einen Puffer will, zielt auf LCP ≤ 2,0 s und INP ≤ 150 ms.

RUM vs. synthetische Tests

Methode	Vorteile	Grenzen
RUM (web-vitals Library, CrUX)	Echte Nutzerdaten, alle Geräte und Verbindungen	Verzögerung (CrUX: 28 Tage), Datenschutz beachten
Synthetische Tests (Lighthouse, WebPageTest)	Sofortige Ergebnisse, reproduzierbar, kein Traffic nötig	Kein echtes Nutzerverhalten, simulierte Bedingungen

Beide Methoden ergänzen sich. RUM zeigt, was Nutzer wirklich erleben. Synthetische Tests helfen beim Debugging und als Release-Gate vor dem Deployment.

Empfehlungen für das Monitoring:

Search Console wöchentlich prüfen, besonders nach Deployments.
Automatisierte Lighthouse-Tests in die CI/CD-Pipeline integrieren.
Alerts einrichten, wenn CrUX-Werte in den „verbesserungswürdig“-Bereich rutschen.
Nach jedem größeren Release einen PageSpeed-Insights-Check durchführen.

Praxis-Checkliste für KMU: Schnelle Wins und wann externe Hilfe sinnvoll ist

Kleine Unternehmen haben selten Zeit für wochenlange Performance-Projekte. Diese Maßnahmen bringen die größte Wirkung mit dem geringsten Aufwand:

1. Search Console einrichten und Core Web Vitals Report prüfen

Ohne Felddaten kein Überblick. Wer Search Console noch nicht nutzt, richtet sie als erstes ein. Der Core Web Vitals Report zeigt sofort, wo Handlungsbedarf besteht.

2. PageSpeed Insights für die wichtigsten Seiten ausführen

Startseite, Kontaktseite und die meistbesuchten Produktseiten zuerst. Die Diagnosehinweise von PageSpeed Insights sind direkt umsetzbar.

3. Bilder auf WebP umstellen und Abmessungen festlegen

Bilder ohne width und height verursachen CLS. Fehlende Bildoptimierung ist oft der größte LCP-Faktor. Beides lässt sich in den meisten CMS ohne Entwickleraufwand beheben.

4. Lazy Loading vom Hero-Bild entfernen

Viele WordPress-Themes setzen loading="lazy" pauschal auf alle Bilder. Das Hero-Bild braucht kein Lazy Loading, es muss sofort laden.

5. Nicht benötigte Plugins und Scripts deaktivieren

Jedes zusätzliche Script erhöht die JavaScript-Last. Ein Plugin-Audit in WordPress oder einem anderen CMS dauert eine Stunde und kann INP und LCP spürbar verbessern.

6. Hosting-Qualität prüfen

Ein TTFB über 800 ms ist fast immer ein Hosting-Problem. Günstiges Shared Hosting ist für Websites mit Conversion-Anspruch oft keine gute Wahl. Ein Wechsel zu einem schnelleren Anbieter ist eine der wirkungsvollsten Einzelmaßnahmen.

7. Caching aktivieren

Serverseitiges Caching und Browser-Caching reduzieren TTFB und Ladezeiten für wiederkehrende Besucher. In WordPress erledigen das Plugins wie WP Rocket oder W3 Total Cache.

8. Eine Relaunch-Checkliste verwenden

Wer seine Website neu aufbaut, sollte Performance von Anfang an einplanen. Eine Website-Relaunch-Checkliste hilft, keine Performance-Punkte zu vergessen.

Wann eine Agentur sinnvoll ist

Manche Probleme lassen sich nicht mit Plugin-Einstellungen lösen:

Das CMS hat strukturelle Grenzen (z. B. erzwungenes JavaScript-Rendering).
Drittanbieter-Scripts sind geschäftskritisch, aber INP-schädlich, und es braucht eine Strategie.
Nach eigenem Audit bleibt der LCP über 4,0 s, ohne klare Ursache.
Ein Relaunch steht an und Performance soll von Anfang an stimmen.

Die Kosten-Nutzen-Rechnung ist einfach: Wenn eine Seite monatlich 1.000 Besucher hat und die Conversion-Rate durch bessere Performance um 0,5 Prozentpunkte steigt, summiert sich das schnell auf messbare Mehreinnahmen, die einen einmaligen Audit-Aufwand rechtfertigen.

Was die Praxis wirklich lehrt

Die häufigste Konstellation in Kundenprojekten: Der LCP ist schlecht, weil das Hero-Bild zu spät entdeckt wird. Nicht weil es zu groß ist, nicht weil der Server langsam ist, sondern weil das Bild als CSS-Hintergrundbild eingebunden ist und der Browser es erst nach dem CSS-Parsing lädt. Ein einziger Wechsel zu einem <img>-Tag mit fetchpriority="high" hat in solchen Fällen den LCP um mehr als eine Sekunde verbessert.

CLS-Probleme kommen fast immer von Consent-Bannern oder nachträglich geladenen Werbeflächen. Der Banner erscheint, schiebt den Inhalt nach unten, und der CLS-Score steigt. Die Lösung ist nicht, den Banner zu entfernen, sondern Platz dafür zu reservieren, bevor er erscheint.

INP ist die komplexeste der drei Metriken, weil sie von Nutzerverhalten abhängt. Seiten mit viel JavaScript-Hydration, etwa durch bestimmte Page-Builder oder Single-Page-Application-Frameworks, kämpfen hier strukturell. In solchen Fällen hilft kein einzelner Fix, sondern eine Architekturentscheidung. Das ist der Moment, an dem externe Expertise den Unterschied macht.

Wer aktuelle Webdesign-Trends im Blick hat, merkt: Performance und Design sind keine Gegensätze mehr. Moderne Frameworks und Build-Tools machen es einfacher denn je, beides gleichzeitig zu erreichen.

Wie Einfach-sichtbar beim Messen und Verbessern unterstützt

Wer nach dem Lesen dieses Artikels weiß, wo das Problem liegt, aber nicht die Zeit oder das technische Setup hat, es selbst zu beheben, bekommt bei Einfach-sichtbar konkrete Unterstützung ohne Agentur-Overhead.

Einfach-sichtbar bietet für KMU in Konstanz und der Bodenseeregion einen strukturierten Ansatz: Erst messen (PageSpeed Insights, Lighthouse, Search Console), dann die Ursachen benennen, dann umsetzen. Das umfasst Bildformate, Hosting-Empfehlungen, Script-Audits und CLS-Fixes, alles mit klarem Fokus auf die Metriken, die Google tatsächlich bewertet. Kein Pauschalpaket, sondern eine Analyse, die zeigt, was Ihre Seite konkret bremst. Besonders sinnvoll ist das vor einem Website-Relaunch, wenn Performance von Anfang an eingebaut werden soll, statt nachträglich geflickt zu werden. Nehmen Sie jetzt Kontakt auf und lassen Sie Ihre Seite analysieren: Einfach-sichtbar.

Quellen

Direkte Links zu den wichtigsten Ressourcen für Diagnose, Messung und Dokumentation: