Core Web Vitals: LCP, INP und CLS verstehen und verbessern

Die kurze Antwort: Was sind Core Web Vitals?

Core Web Vitals sind drei Kennzahlen, mit denen Google messen lässt, wie sich eine Website für echte Besucher anfühlt. Sie betreffen das Laden (Largest Contentful Paint, LCP), die Reaktion auf Eingaben (Interaction to Next Paint, INP) und die visuelle Stabilität (Cumulative Layout Shift, CLS). Als „gut" gilt eine Seite laut web.dev, wenn LCP bei höchstens 2,5 Sekunden liegt, INP bei höchstens 200 Millisekunden und CLS bei höchstens 0,1 – jeweils beim 75. Perzentil der Seitenaufrufe, getrennt nach Mobil und Desktop.

Das bedeutet: Drei von vier Besuchen müssen den Grenzwert einhalten, nicht der Durchschnitt. Eine Seite besteht die Bewertung nur, wenn alle drei Werte im grünen Bereich liegen.

Dieser Ratgeber ist für Inhaberinnen und Inhaber gedacht, die Messwerte lesen und Aufträge an Entwickler oder Agenturen sauber formulieren möchten. Er ersetzt keine technische Analyse Ihrer konkreten Seite, hilft aber, die richtigen Fragen zu stellen.

Die drei Kennzahlen im Überblick

Die Schwellen für „Verbesserungsbedarf" und „schlecht" stammen aus der Hilfe zum Core-Web-Vitals-Bericht der Search Console. Dort bestimmt die schwächste der drei Kennzahlen den Gesamtstatus einer URL-Gruppe.

Largest Contentful Paint (LCP)

LCP stoppt die Uhr, sobald das größte Inhaltselement im sichtbaren Bereich gerendert ist. Bei einer Praxis- oder Restaurantseite ist das meist das große Titelbild, bei reinen Textseiten die Hauptüberschrift. Für Ihren Entwickler wichtig: Auch der LCP setzt sich aus vier Teilen zusammen, nämlich der Serverantwortzeit (TTFB), der Verzögerung vor dem Laden der Ressource, der Ladedauer der Ressource und der Verzögerung bis zur Darstellung. web.dev nennt als Richtgröße ungefähr 40 % für TTFB, unter 10 % für die Verzögerung vor dem Ladebeginn, rund 40 % für die Ladedauer und unter 10 % für die Darstellungsverzögerung. Wer nur einen Teil verkürzt, verschiebt die Zeit manchmal bloß in einen anderen – deshalb sollten alle vier betrachtet werden.

Interaction to Next Paint (INP)

INP beobachtet die Reaktionszeit über die gesamte Nutzung einer Seite: Menü öffnen, Filter anwenden, Formular absenden. Gemeint ist die Zeit vom Klick bis zur nächsten sichtbaren Aktualisierung. INP hat First Input Delay (FID) abgelöst; laut web.dev geschah das am 12. März 2024. Alte Berichte, die noch FID ausweisen, sollten Sie nicht mehr als Maßstab nehmen.

Ein Praxisfall: Ein Mobilmenü, das nach dem Tippen eine halbe Sekunde „hängt", weil im Hintergrund gerade ein Skript läuft, schlägt sich im INP nieder – auch wenn die Seite zuvor schnell geladen hat.

Cumulative Layout Shift (CLS)

CLS misst das Verrutschen von Inhalten. Jeder kennt den Moment, in dem man auf einen Button tippen will und die Seite im selben Augenblick ein Banner nachlädt. Ein niedriger CLS bedeutet: Elemente haben von Anfang an ihren Platz.

Feld- und Labordaten: Welche Zahl zählt?

Die Unterscheidung ist der häufigste Stolperstein bei der Pagespeed-Optimierung.

Felddaten stammen von echten Besuchern. Die Quelle ist der Chrome User Experience Report (CrUX), der Verteilungen aus einem Zeitraum von 28 Tagen enthält. Für die Bewertung wird das 75. Perzentil der Verteilung herangezogen.

Labordaten entstehen, wenn ein Werkzeug wie Lighthouse eine Seite unter festgelegten Bedingungen lädt: simuliertes Gerät, simuliertes Netz. Sie sind reproduzierbar und gut zur Fehlersuche, bilden aber nicht ab, wer Ihre Seite tatsächlich besucht.

Die beiden Werte weichen oft voneinander ab. web.dev nennt dafür Gründe: Im Labor kann ein anderes LCP-Element erkannt werden als bei echten Nutzern (Bildschirmgröße, Personalisierung, A/B-Tests). Zwischengespeicherte Seiten und der Zurück-Button machen reale Besuche schneller. INP lässt sich im Labor nicht direkt messen, weil niemand vorhersagen kann, wann echte Nutzer interagieren. Und CLS erfasst im Labor meist nur Verschiebungen beim initialen Laden, im Feld auch solche beim Scrollen oder durch nachgeladene, personalisierte Inhalte.

Die Empfehlung von web.dev: Felddaten haben Vorrang, Labordaten helfen, Ursachen zu finden und Verbesserungen vor dem Livegang zu prüfen.

Rolle im Google-Ranking: wie Google es formuliert

Google schreibt in der Search-Central-Dokumentation, dass Core Web Vitals die tatsächliche Nutzererfahrung messen, und empfiehlt Websitebetreibern ausdrücklich, gute Werte für den Erfolg in der Suche anzustreben. Die Core Web Vitals würden von den Ranking-Systemen genutzt und passten, zusammen mit anderen Aspekten der Seitenerfahrung („page experience"), zu dem, was die zentralen Ranking-Systeme belohnen wollen.

Wichtig sind drei Einschränkungen, die Google selbst nennt:

• Es gibt kein einzelnes „Page-Experience-Signal". Die Ranking-Systeme berücksichtigen mehrere Signale.
• Google will weiterhin das relevanteste Ergebnis zeigen, auch wenn dessen Seitenerfahrung schwächer ist. Eine gute Seitenerfahrung kann helfen, wenn viele hilfreiche Seiten um dieselbe Suchanfrage konkurrieren, ersetzt aber keine Relevanz.
• Gute Werte im Bericht oder in Drittwerkzeugen garantieren keine Spitzenplatzierung. Google rät davon ab, perfekte Werte nur um des Rankings willen anzustreben.

Praktisch heißt das: Core Web Vitals sind ein sinnvolles Qualitätsziel, aber keine Abkürzung zu Platz eins. Der Nutzen liegt zuerst bei den Besuchern, die eine schnelle, stabile Seite seltener verlassen. Wer zudem Anfragen über die Website gewinnen will, hat damit einen handfesten Grund, die Technik ernst zu nehmen.

So messen Sie selbst

Sie brauchen dafür weder Programmierkenntnisse noch Zugriff auf den Server. Gehen Sie in dieser Reihenfolge vor:

1. Google Search Console öffnen. Wenn Ihre Domain dort als Property eingerichtet ist, finden Sie den Bericht „Core Web Vitals". Er nutzt ausschließlich Felddaten aus CrUX, trennt Mobil und Desktop und fasst ähnliche Seiten zu URL-Gruppen zusammen. Der Status einer Gruppe (gut, verbesserungswürdig, schlecht) folgt der schwächsten Kennzahl. Der Bericht zeigt nur eine Auswahl indexierter URLs, nicht jede einzelne Seite.
2. Schwächste Gruppe öffnen. Notieren Sie, welche Kennzahl (LCP, INP oder CLS) den Status verursacht und auf welchem Gerätetyp.
3. PageSpeed Insights für eine Beispielseite aus dieser Gruppe aufrufen. Dort sehen Sie oben Felddaten der letzten 28 Tage (zuerst für die URL, falls genug Daten vorliegen, sonst für die gesamte Domain) und darunter Labordaten von Lighthouse samt konkreten Hinweisen. Lighthouse bewertet seine Performance-Punktzahl mit 90 oder mehr als gut, 50 bis 89 als verbesserungswürdig und darunter als schlecht – diese Punktzahl ist aber nicht identisch mit der Core-Web-Vitals-Bewertung.
4. Mobil und Desktop getrennt betrachten. Auf Mobilgeräten sind Werte oft schlechter, weil Prozessor und Netz schwächer sind.
5. Nach Änderungen warten. Weil CrUX über 28 Tage mittelt, zeigt sich eine Verbesserung erst nach und nach in den Felddaten. Prüfen Sie kurzfristig mit Lighthouse, ob die Änderung technisch greift.

Fehlen Felddaten („Keine Daten verfügbar"), ist das bei neuen oder wenig besuchten Websites normal. Die Search-Console-Hilfe empfiehlt dann PageSpeed Insights oder Lighthouse für Livetests einzelner URLs.

Praktische Maßnahmen je Kennzahl

Die folgenden Punkte sind als Briefing-Grundlage für Ihren Entwickler gedacht. Sie müssen die Umsetzung nicht selbst beherrschen, aber Sie sollten wissen, wonach Sie fragen.

LCP verbessern

Bilder. Das Titelbild ist häufig das LCP-Element. web.dev empfiehlt moderne Formate wie AVIF oder WebP, weil sie in der Regel besser komprimieren als ältere Formate, mit JPEG oder PNG als Rückfall für sehr alte Browser, passende Abmessungen statt überdimensionierter Originale und Komprimierung. Für Logos und Icons eignet sich SVG.

LCP-Bild nicht verzögern. Das LCP-Bild darf niemals mit Lazy-Loading versehen werden, denn das verzögert genau das Element, auf das es ankommt. Es sollte direkt im HTML auffindbar sein; wird es nur über CSS oder JavaScript eingebunden, hilft ein Preload. Das Attribut fetchpriority="high" markiert das wichtigste Bild, sollte aber nur bei einem oder zwei Bildern gesetzt werden.

Serverantwortzeit. Ein CDN, möglichst auf derselben Domain wie das HTML, sowie wirksames Caching verkürzen die Wartezeit auf die erste Antwort. Vermeiden Sie unnötige Weiterleitungen und Cache-umgehende URL-Parameter.

Render-Blockaden. Kritisches CSS klein halten oder einbetten, unkritisches CSS nachladen, keine synchronen Skripte im <head>.

JavaScript-Rendering. Wird der Hauptinhalt erst per JavaScript im Browser aufgebaut, verzögert das die Darstellung. web.dev nennt serverseitiges Rendering oder Prerendering als Gegenmittel. Bei WordPress-Themes mit vielen Bausteinen oder bei Single-Page-Anwendungen lohnt die Nachfrage, wie der Inhalt ausgeliefert wird. Mehr zur Technikwahl steht im Ratgeber zu WordPress-Websites.

Schriften. Schriften sind Teil des Ladevorgangs. Laut web.dev sollten Sie WOFF2 nutzen, Schriften auf die benötigten Zeichen reduzieren (Subsetting) und die Anzahl der Schriftschnitte begrenzen, etwa mit Systemschriften oder einer variablen Schrift. Selbst gehostete Schriften sind vorteilhaft, wenn zugleich ein CDN und HTTP/2 im Einsatz sind; andernfalls kann eine externe Schriftquelle sogar schneller sein. Klären Sie außerdem, ob die Schriftlizenz Selbsthosting erlaubt. Mit font-display steuern Sie, was angezeigt wird, bis die Schrift geladen ist.

INP verbessern

Lange Aufgaben vermeiden. INP leidet, wenn der Browser mit Skripten beschäftigt ist und Eingaben nicht sofort verarbeitet. Der Entwickler sollte lange Aufgaben aufteilen und Arbeit, die nicht sofort nötig ist, später ausführen.

Drittanbieter-Skripte. Chat-Widgets, Tracking, Terminbuchung, Karten, Social-Media-Einbettungen: Jedes Skript kostet Rechenzeit. web.dev rät, Skripte von Drittanbietern mit async oder defer zu laden, sofern sie nicht für das erste Rendering nötig sind, frühzeitig eine Verbindung zu den Fremd-Servern aufzubauen (preconnect), Skripte ohne klaren Nutzen zu entfernen und eingebettete Inhalte wie Videos erst bei Bedarf zu laden. Selbst gehostete Skripte erhalten keine automatischen Updates; Sicherheits- und API-Änderungen müssen Sie dann selbst nachziehen.

Große Seitenstruktur. Sehr große DOM-Strukturen machen das Rendern langsamer. Flachere Strukturen und das Nachladen von Inhalt erst bei Interaktion helfen.

Client-seitiges Rendern von viel HTML. Wird viel Markup per JavaScript erzeugt, kann der Browser nicht zwischendurch auf Eingaben reagieren. Weniger JavaScript, nur wo es gebraucht wird, ist die robusteste Lösung.

CLS verbessern

Bilder und Videos mit Abmessungen. Setzen Sie width und height oder das CSS-Attribut aspect-ratio, damit der Browser den Platz schon vor dem Laden reserviert.

Banner, Werbung, Einbettungen. Für Cookie-Banner, Anzeigen und eingebettete Karten oder Videos muss ein fester Platz vorgesehen sein (min-height oder aspect-ratio). Auch das Zusammenklappen eines leeren Werbeplatzes erzeugt Verschiebungen; ein Platzhalter ist besser. Dynamische Inhalte sollten möglichst weiter unten erscheinen oder erst nach einer Nutzeraktion geladen werden.

Schriftwechsel. Sowohl unsichtbarer Text als auch der Wechsel von Ersatz- auf Webschrift können Layout verschieben. web.dev nennt font-display: optional, eine Ersatzschrift mit ähnlichen Metriken (size-adjust) und den Preload kritischer Schriften.

Animationen. Animationen über transform verursachen keine Neuberechnung des Layouts, Animationen über top oder left schon.

Symptom, Ursache, Auftrag

Die Tabelle fasst die Hinweise von web.dev so zusammen, dass Sie sie direkt in ein Briefing übernehmen können. „Wahrscheinliche Ursache" heißt: Das ist die erste Vermutung, nicht die Diagnose. Ein Entwickler muss sie an Ihrer Seite prüfen.

Was Sie von Ihrem Entwickler verlangen sollten

Ein belastbares Auftragsbriefing enthält:

• Ausgangswerte: Screenshots oder Notizen aus Search Console und PageSpeed Insights mit Datum, getrennt nach Mobil und Desktop.
• Zielwerte: Die Grenzwerte LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 – bezogen auf Felddaten, nicht auf eine Lighthouse-Punktzahl.
• Betroffene Seitentypen: Startseite, Leistungsseiten, Kontaktseite, Artikel. Nicht jede Seite hat dasselbe Problem.
• Drittanbieter-Inventur: Welche externen Skripte laufen, wer braucht sie, was kostet jedes an Ladezeit?
• Prüfung nach der Umsetzung: Wiederholung der Labormessung sofort, Kontrolle der Felddaten nach einigen Wochen.

Seien Sie vorsichtig bei Angeboten, die „100 Punkte bei PageSpeed" garantieren. Die Lighthouse-Punktzahl ist eine Labor-Kennzahl und nicht die Bewertung, die Google in der Search Console zeigt. Auch Google selbst rät, nicht allein um des Rankings willen perfekte Werte anzustreben.

Wenn Ihre Website regelmäßig gepflegt wird, gehören Updates, die Prüfung von Plugins und das Entfernen alter Skripte zur laufenden Arbeit. Wie das aussieht, beschreibt der Ratgeber zur Website-Wartung. Wer vor einem Neubau steht, findet die Entscheidungshilfe zu Aufwand und Ablauf im Ratgeber Homepage erstellen lassen. Eine Übersicht aller Themen bietet der Ratgeber-Bereich.

Das Wichtigste in Kürze und Ihr nächster Schritt

Gute Core Web Vitals bedeuten: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1 beim 75. Perzentil echter Besucher. Sie sind ein Qualitätsmerkmal, das Google in seinen Ranking-Systemen berücksichtigt, aber kein Ersatz für relevante Inhalte.

Ihr nächster Schritt: Öffnen Sie heute den Bericht „Core Web Vitals" in der Search Console, notieren Sie die schwächste Gruppe samt Kennzahl, prüfen Sie eine Beispielseite in PageSpeed Insights und geben Sie diese Ausgangswerte mit der Symptom-Ursache-Auftrag-Tabelle an Ihren Entwickler weiter.

Dieser Ratgeber erklärt Zusammenhänge allgemein und ersetzt keine technische Analyse Ihrer Website. Er bietet keine Rechts- oder Einzelfallberatung.