Eine Landingpage kann noch so gut getextet sein: Wenn das Hauptbild ewig lädt, der Button verzögert reagiert oder der Text beim Scrollen springt, sind Besucher weg. Genau diese drei Erlebnisse messen die Core Web Vitals. Google nutzt sie, um die Nutzererfahrung einer Seite in Zahlen zu fassen.
Für Marketingteams sind die Messwerte deshalb weit mehr als ein Technikthema. Sie beeinflussen, wie viele Besucher deine Inhalte überhaupt wahrnehmen, wie viele Formulare abgeschickt werden und wie gut deine Kampagnen-Landingpages konvertieren.
In diesem Beitrag erfährst du, was hinter LCP, INP und CLS steckt, wie du sie richtig misst und mit welchen Maßnahmen du sie verbesserst – auch ohne selbst Entwicklerin oder Entwickler zu sein.
Core Web Vitals sind drei von Google definierte Messwerte für die Nutzererfahrung einer Webseite: Largest Contentful Paint (LCP) für die Ladegeschwindigkeit, Interaction to Next Paint (INP) für die Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für die visuelle Stabilität. Gemessen wird mit Daten echter Nutzer, getrennt nach Mobilgerät und Desktop.
Was sind Core Web Vitals? Die drei Messwerte im Überblick
Google hat die Core Web Vitals als Teil der Initiative Web Vitals eingeführt, um Website-Betreibern wenige, klar verständliche Zielwerte zu geben. Laut web.dev durchlaufen die Messwerte einen festen Lebenszyklus, und stabile Werte ändern sich höchstens einmal pro Jahr. Seit März 2024 hat INP den früheren Messwert First Input Delay (FID) abgelöst.
| Messwert | Misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladezeit des größten sichtbaren Elements | bis 2,5 s | bis 4,0 s | über 4,0 s |
| INP | Reaktionszeit auf Interaktionen | bis 200 ms | bis 500 ms | über 500 ms |
| CLS | Verschiebung von Inhalten beim Laden | bis 0,1 | bis 0,25 | über 0,25 |
Warum das 75. Perzentil zählt
Eine Seite besteht die Core Web Vitals, wenn sie bei mindestens 75 Prozent der Seitenaufrufe alle drei Zielwerte erreicht. Google bewertet also nicht den Durchschnitt, sondern einen Wert, der auch langsame Geräte und schwache Mobilfunkverbindungen berücksichtigt. Ein schneller Test auf deinem Bürorechner sagt deshalb wenig darüber aus, was deine Kundschaft unterwegs erlebt.
Felddaten statt Gefühl
Die offiziellen Werte stammen aus dem Chrome User Experience Report, kurz CrUX. Er sammelt anonymisierte Messungen von Chrome-Nutzern, die der Übermittlung zugestimmt haben. Seiten mit wenig Traffic tauchen dort manchmal gar nicht auf – dann bewertet Google größere Gruppen ähnlicher Seiten oder die gesamte Domain.
Largest Contentful Paint (LCP): Ladezeit verstehen und verbessern
LCP misst, wann das größte sichtbare Element im ersten Bildschirmausschnitt fertig dargestellt ist. Meist ist das ein Hero-Bild, ein Video-Vorschaubild oder eine große Überschrift. Für Besucher ist das der Moment, in dem die Seite „da“ wirkt.
Welches Element als LCP zählt, kann sich je nach Bildschirmgröße unterscheiden. Auf dem Smartphone ist es oft eine Überschrift, auf dem Desktop ein großes Bild. PageSpeed Insights zeigt dir für jede URL an, welches Element gemessen wurde – damit weißt du, wo du ansetzen musst.
Die vier Teilzeiten von LCP
Der Leitfaden LCP optimieren zerlegt den Wert in vier Abschnitte, die sich lückenlos addieren:
- Time to First Byte: Zeit, bis der Server das erste Byte HTML liefert.
- Ladeverzögerung der Ressource: Zeit, bis der Browser überhaupt mit dem Laden des LCP-Bildes beginnt.
- Ladedauer der Ressource: Zeit für den eigentlichen Download des Bildes.
- Renderverzögerung: Zeit zwischen fertigem Download und sichtbarer Darstellung.
Idealerweise entfallen Serverantwort und Download jeweils auf rund 40 Prozent der Gesamtzeit, die beiden Verzögerungen sollten nahe null liegen. So erkennst du schnell, wo deine Seite Zeit verliert.
Maßnahmen für einen besseren LCP
- Komprimiere das Hero-Bild und liefere es in modernen Formaten wie WebP oder AVIF in passender Größe aus.
- Setze beim LCP-Bild das Attribut fetchpriority="high", damit der Browser es bevorzugt lädt.
- Verzichte beim LCP-Bild auf Lazy Loading – web.dev warnt ausdrücklich davor.
- Nutze Caching, ein Content Delivery Network und schnelles Hosting, um die Serverantwort zu verkürzen.
- Ersetze Slider im ersten Bildschirmausschnitt durch ein einzelnes, aussagekräftiges Motiv.
Interaction to Next Paint (INP): Wie schnell deine Seite reagiert
INP beschreibt, wie zügig eine Seite auf Klicks, Tipps und Tastatureingaben reagiert. Laut web.dev zu INP zählen nur diese drei Interaktionsarten, Scrollen und Hovern bleiben außen vor. Der Wert berücksichtigt die Interaktionen während des gesamten Besuchs, nicht nur die erste.
Die drei Phasen einer Interaktion
Jede Interaktion besteht aus drei Abschnitten. Die Eingabeverzögerung entsteht, wenn der Browser noch mit anderen Aufgaben beschäftigt ist. Es folgen die Verarbeitungszeit der Skripte und schließlich die Darstellungsverzögerung bis zum nächsten sichtbaren Bild. Alle drei Phasen zusammen ergeben die Zeit, die INP für eine Interaktion meldet.
Marketing-Tags als häufige Bremse
In Marketingabteilungen liegt die Ursache für schlechte INP-Werte oft im eigenen Werkzeugkasten. Tracking-Pixel, Chat-Widgets, A/B-Testing-Tools, Heatmaps und Consent-Banner laden JavaScript, das den Hauptthread blockiert. Jedes Tool für sich wirkt harmlos, in Summe bremsen sie die Reaktionsfähigkeit spürbar.
Prüfe deshalb regelmäßig, welche Tags wirklich noch gebraucht werden. Unser Beitrag zum schlanken Martech-Stack zeigt, wie du Werkzeuge konsolidierst. Wie du trotz weniger Skripte belastbar misst, beschreibt der Leitfaden zur Attribution ohne Cookies.
Besonders kritisch ist der Moment direkt nach dem Laden. Viele Besucher klicken sofort auf das Consent-Banner oder das Menü – genau dann, wenn zahlreiche Skripte gleichzeitig starten. Ein Tag-Manager, der nicht benötigte Tags erst nach der Einwilligung oder nach dem ersten Rendern lädt, entlastet diese Phase deutlich.
Maßnahmen für einen besseren INP
- Entferne ungenutzte Tags und Plugins und lade verbleibende Skripte verzögert, wo es möglich ist.
- Teile lange JavaScript-Aufgaben in kleinere Abschnitte auf, damit der Browser zwischendurch reagieren kann.
- Gib Nutzern sofort sichtbares Feedback, etwa einen Ladezustand am Button.
- Teste Formulare und Filter auf günstigen Android-Geräten, nicht nur auf aktuellen Smartphones.
Cumulative Layout Shift (CLS): Stabilität ohne Sprünge
CLS misst, wie stark sich sichtbare Inhalte unerwartet verschieben. Du kennst das: Du willst auf einen Link tippen, ein Werbebanner lädt nach, und du landest auf dem falschen Ziel. Solche Sprünge frustrieren und kosten Vertrauen.
Typische Ursachen
- Bilder, Videos und iFrames ohne feste Breite und Höhe
- nachladende Werbeanzeigen, Banner und Cookie-Hinweise, die Inhalte nach unten schieben
- Webfonts, die spät eingeblendet werden und Textblöcke vergrößern
- dynamisch eingefügte Elemente wie Newsletter-Boxen oberhalb des Inhalts
Maßnahmen für einen besseren CLS
Reserviere für jedes Medium und jeden Werbeplatz den benötigten Raum, etwa über Breiten- und Höhenangaben oder feste Seitenverhältnisse. Blende Hinweise als Überlagerung ein, statt den Inhalt zu verschieben. Lade Schriftarten so, dass Ersatzschrift und finale Schrift ähnlich viel Platz brauchen.
Beispiel: Der springende Kaufen-Button
Ein fiktives Beispiel: Auf einer Produktseite lädt ein Bewertungs-Widget erst nach zwei Sekunden und schiebt den Warenkorb-Button um 200 Pixel nach unten. Mobile Besucher tippen ins Leere oder auf ein falsches Element. Das Team reserviert für das Widget einen festen Platzhalter – der Button bleibt stehen, und der CLS-Wert sinkt deutlich.
Core Web Vitals messen: Felddaten und Labordaten
Für die Core Web Vitals gibt es zwei Arten von Daten. Felddaten zeigen, was echte Nutzer erleben, Labordaten simulieren einen Seitenaufruf unter festen Bedingungen. Beide haben ihren Platz, aber nur Felddaten bilden die Wirklichkeit ab.
| Werkzeug | Datenart | Wofür geeignet |
|---|---|---|
| Search Console, Bericht Core Web Vitals | Felddaten | Überblick über Seitengruppen |
| PageSpeed Insights | Feld- und Labordaten | Analyse einzelner URLs |
| Chrome DevTools | Labordaten, lokale Messung | Fehlersuche im Detail |
| Lighthouse | Labordaten | schnelle Checks, kein INP |
| web-vitals-Bibliothek | eigene Felddaten | Messung in der eigenen Webanalyse |
Lighthouse kann INP nicht messen, weil im Labortest niemand klickt. Als Ersatzwert dient dort die Total Blocking Time. Den Bericht in der Google Search Console nutzt du am besten als Frühwarnsystem: Er gruppiert ähnliche URLs, sodass du Probleme in Vorlagen schnell erkennst.
Mobil zuerst prüfen
Auf Smartphones fallen die Werte fast immer schlechter aus als auf dem Desktop. Prozessoren sind schwächer, Verbindungen schwanken. Beginne deine Analyse deshalb mit den mobilen Daten und priorisiere die Seiten mit dem meisten Traffic.
Eigene Felddaten erheben
CrUX liefert nur Daten für Seiten mit ausreichend Traffic und reagiert mit Verzögerung. Mit der kostenlosen web-vitals-Bibliothek misst du die Core Web Vitals direkt bei deinen Besuchern und überträgst sie in deine Webanalyse. So siehst du schon nach wenigen Tagen, ob eine Änderung wirkt, und kannst die Werte nach Seitentyp oder Kampagne auswerten.
Wie wichtig sind Core Web Vitals fürs Ranking?
Google ordnet die Messwerte klar ein. In der Dokumentation zu Core Web Vitals in der Google-Suche heißt es, sie entsprächen dem, was die Kernsysteme für das Ranking belohnen wollen. Google empfiehlt Website-Betreibern ausdrücklich, gute Werte zu erreichen.
Gleichzeitig gilt: Gute Core Web Vitals garantieren keine Top-Platzierung. Relevanz und Qualität des Inhalts bleiben entscheidend. Ein hervorragender Artikel mit mittelmäßiger Ladezeit schlägt in der Regel einen schnellen, aber dünnen Text.
Der eigentliche Gewinn liegt in der Conversion
Der größere Hebel liegt oft hinter dem Klick. Wer bezahlten Traffic auf eine langsame Landingpage schickt, zahlt für Besucher, die vor dem ersten Eindruck abspringen. Gerade bei Kampagnen lohnt sich deshalb ein Blick auf die Werte, bevor das Budget fließt.
Prüfe vor jedem Kampagnenstart die wichtigsten Landingpages in PageSpeed Insights. Liegt der mobile LCP deutlich über 2,5 Sekunden, kläre zuerst Bildgrößen und Skripte, bevor du Budget freigibst.
Auch für KI-Suchsysteme zählt eine schlanke Seite: Inhalte, die schnell und direkt im HTML verfügbar sind, lassen sich leichter auslesen. Mehr dazu liest du im Beitrag zur Generative Engine Optimization.
Core Web Vitals im Team verankern
Gute Werte sind kein einmaliges Projekt. Jedes neue Plugin, jedes Kampagnen-Tag und jedes ungeprüfte Bild kann sie wieder verschlechtern. Deshalb brauchst du klare Zuständigkeiten.
- Marketing verantwortet Bilder, eingebundene Tools und neue Landingpages.
- Entwicklung kümmert sich um Vorlagen, Skripte, Caching und Server.
- Redaktion achtet auf komprimierte Bilder und sparsame Einbettungen.
Lege außerdem ein Performance-Budget fest, etwa eine maximale Bildgröße oder eine Obergrenze für zusätzliche Skripte. Neue Tools kommen nur auf die Website, wenn sie das Budget einhalten oder ein altes Werkzeug ersetzen. Ein fiktives Beispiel: Ein Team entfernt drei ungenutzte Tracking-Tags, bevor es ein neues Chat-Widget einbindet.
Halte die Ergebnisse in einem kurzen monatlichen Bericht fest, damit Erfolge und Rückschritte für alle Beteiligten sichtbar bleiben.
Core Web Vitals bei WordPress und Baukastensystemen
Viele Unternehmenswebsites laufen auf WordPress oder einem Baukasten. Hier entscheiden Theme, Page Builder und Plugins über einen Großteil der Performance. Ein schweres Theme mit Animationen und Schriftarten-Paketen lässt sich auch mit Optimierungs-Plugins nur begrenzt retten.
Prüfe vor jeder Installation, ob ein Plugin auf allen Seiten Skripte lädt oder nur dort, wo es gebraucht wird. Caching- und Bildoptimierungs-Plugins helfen, ersetzen aber keine schlanke Grundlage. Bei einem Relaunch lohnt es sich, die Core Web Vitals schon bei der Auswahl des Themes zu testen.
Deine nächsten Schritte
Mit diesem Ablauf verbesserst du deine Core Web Vitals strukturiert statt nach Gefühl:
- Öffne den Bericht zu den Core Web Vitals in der Search Console und notiere die schlechtesten Seitengruppen, zuerst mobil.
- Analysiere je eine Beispiel-URL pro Gruppe in PageSpeed Insights und bestimme den kritischen Messwert.
- Prüfe alle Marketing-Tags und entferne, was niemand mehr auswertet.
- Behebe die Ursache in der Vorlage, nicht auf einzelnen Seiten.
- Starte in der Search Console die Validierung und beobachte die Felddaten über die nächsten 28 Tage.
Wiederhole den Check nach jedem größeren Relaunch oder Tool-Wechsel. So bleiben deine Seiten dauerhaft schnell, stabil und reaktionsfreudig.
Häufige Fragen zu Core Web Vitals
Was sind Core Web Vitals?
Core Web Vitals sind drei Messwerte von Google für die Nutzererfahrung: LCP für die Ladezeit des größten sichtbaren Elements, INP für die Reaktionszeit auf Klicks und Eingaben und CLS für die visuelle Stabilität. Eine Seite besteht, wenn sie bei 75 Prozent der Aufrufe alle drei Zielwerte erreicht.
Welche Werte gelten bei den Core Web Vitals als gut?
Als gut gelten ein LCP von höchstens 2,5 Sekunden, ein INP von höchstens 200 Millisekunden und ein CLS von höchstens 0,1. Maßgeblich ist jeweils das 75. Perzentil der Seitenaufrufe, getrennt nach Mobilgeräten und Desktop. Werte über 4 Sekunden, 500 Millisekunden oder 0,25 gelten als schlecht.
Warum zeigt PageSpeed Insights andere Werte als die Search Console?
PageSpeed Insights zeigt Felddaten für eine einzelne URL und zusätzlich einen simulierten Labortest. Die Search Console fasst Felddaten mehrerer ähnlicher Seiten zu Gruppen zusammen. Labortests laufen unter festen Bedingungen und bilden echte Geräte und Verbindungen nur näherungsweise ab, deshalb weichen die Zahlen oft voneinander ab.
Was hat INP ersetzt?
INP hat im März 2024 den Messwert First Input Delay ersetzt. FID maß nur die Verzögerung bis zur Verarbeitung der ersten Interaktion. INP berücksichtigt dagegen Klicks, Tipps und Tastatureingaben während des gesamten Besuchs und erfasst zusätzlich die Zeit bis zur sichtbaren Reaktion. Damit bildet er die Reaktionsfähigkeit deutlich realistischer ab.
Wie lange dauert es, bis Verbesserungen der Core Web Vitals sichtbar werden?
Die Felddaten in CrUX und Search Console beziehen sich auf einen gleitenden Zeitraum von 28 Tagen. Nach einer technischen Verbesserung dauert es deshalb einige Wochen, bis sich die Werte vollständig verändern. Labortests in PageSpeed Insights oder Lighthouse zeigen den Effekt dagegen sofort und eignen sich zur schnellen Kontrolle.
