Definition
Core Web Vitals sind drei Kennzahlen von Google, die die Nutzererfahrung einer Webseite bei echten Besuchen erfassen: Largest Contentful Paint (LCP) misst das Laden, Interaction to Next Paint (INP) die Reaktion auf Eingaben und Cumulative Layout Shift (CLS) die visuelle Stabilität. Gut sind höchstens 2,5 Sekunden, 200 Millisekunden und 0,1 bei drei von vier Seitenaufrufen.
Das Wichtigste in Kürze
- LCP misst das Laden, INP die Reaktion auf Eingaben, CLS das Verrutschen von Inhalten. Gut sind höchstens 2,5 s, 200 ms und 0,1.
- Google nutzt die Core Web Vitals im Ranking als eines von vielen Signalen. Relevante Inhalte gehen vor, gute Werte garantieren keinen Platz.
- Für die Google-Suche zählen Felddaten echter Chrome-Besuche aus dem Chrome UX Report. Lighthouse misst im Labor und hilft bei der Fehlersuche.
- Felddaten stammen nur aus Chrome. iPhones fehlen darin, in Deutschland im Oktober 2026 rund 28 % der mobilen Seitenaufrufe.
- Gute LCP-Werte haben weniger Websites als gute INP- und CLS-Werte. Hebel sind früh ladende Bilder, schnelle Server, reservierter Platz und wenig JavaScript.
Was messen LCP, INP und CLS?
LCP misst, wann das größte Bild, der größte Textblock oder das größte Video im sichtbaren Bereich erscheint. INP misst, wie schnell eine Seite nach einem Klick, Tippen oder Tastendruck sichtbar reagiert. CLS misst, wie stark Inhalte unerwartet verrutschen. Bewertet wird jeweils der Wert, den drei von vier Seitenaufrufen erreichen oder übertreffen.
Google hat die Grenzen aus Forschung zur menschlichen Wahrnehmung und aus Daten echter Websites abgeleitet (web.dev, Grenzwerte (externe Website)). Sie gelten für Smartphone und Desktop gleich, ausgewertet wird aber jede Geräteart für sich. Eine Seite besteht die Prüfung erst, wenn alle drei Kennzahlen gut sind (web.dev, Web Vitals (externe Website)).
| Kennzahl | misst | gut | verbesserungswürdig | schlecht |
|---|---|---|---|---|
| Largest Contentful Paint (LCP) | Laden: Darstellung des größten sichtbaren Elements | bis 2,5 s | über 2,5 bis 4,0 s | über 4,0 s |
| Interaction to Next Paint (INP) | Reaktion auf Klicks, Tippen und Tastendrücke | bis 200 ms | über 200 bis 500 ms | über 500 ms |
| Cumulative Layout Shift (CLS) | visuelle Stabilität: unerwartetes Verrutschen von Inhalten | bis 0,1 | über 0,1 bis 0,25 | über 0,25 |
- LCP zählt ab dem Aufruf der Seite, also mit Weiterleitungen und der Antwortzeit des Servers. Infrage kommen Bilder, Videos, Hintergrundbilder und Textblöcke. Elemente, die den ganzen Bildschirm füllen, zählen Chrome und Edge zum Hintergrund und berücksichtigen sie nicht (web.dev zu LCP (externe Website)).
- INP erfasst alle Klicks, Tipp- und Tastatureingaben während eines Besuchs und meldet die langsamste. Bei vielen Eingaben fällt je 50 Interaktionen der langsamste Ausreißer weg. Scrollen, Zoomen und das Überfahren mit der Maus zählen nicht. Laut Chrome-Daten verbringen Nutzer 90 % ihrer Zeit auf einer Seite nach dem Laden (web.dev zu INP (externe Website)).
- CLS fasst Layoutverschiebungen zu Serien zusammen: weniger als eine Sekunde Abstand, höchstens fünf Sekunden lang. Es zählt die Serie mit der größten Summe. Verschiebungen bis 500 Millisekunden nach einer Eingabe bleiben außen vor, weil Nutzer sie erwarten (web.dev zu CLS (externe Website)).
Wie die drei Kennzahlen mit Indexierung, Crawling und den übrigen technischen Grundlagen zusammenhängen, ordnet unser Leitfaden zu technischem SEO ein.
Wie wichtig sind Core Web Vitals für das Google-Ranking?
Google nutzt die Core Web Vitals in seinen Ranking-Systemen als eines von vielen Signalen. Die relevanteste Seite zeigt Google auch dann, wenn ihre Nutzerfreundlichkeit schwächer ist. Gibt es zu einer Suche viele hilfreiche Seiten, können gute Werte zum Erfolg beitragen. Eine Platzierung garantieren sie nicht.
So beschreibt es Google in seiner Dokumentation zur Nutzerfreundlichkeit von Seiten (externe Website), Stand 24.09.2026. Ein einzelnes Signal für die Nutzerfreundlichkeit gibt es danach nicht. Google bewertet Seiten in der Regel einzeln, nennt aber auch Bewertungen für die ganze Website. Gute Ergebnisse im Bericht der Search Console oder in Werkzeugen anderer Anbieter sichern keinen Platz ganz oben. Wer nur der Suchmaschine wegen einen perfekten Wert anstrebt, hat laut Google wahrscheinlich Wichtigeres zu tun.
Grundlage sind Felddaten: Die Messwerte echter Chrome-Besuche aus dem Chrome UX Report (CrUX) nutzt die Google-Suche für den Rankingfaktor Nutzerfreundlichkeit (Chrome for Developers, CrUX (externe Website)). Angekündigt hat Google diesen Rankingfaktor im Mai 2020, eingeführt wurde er von Juni bis Ende August 2021 (Google Search Central Blog (externe Website)).
Nicht belegt sind diese verbreiteten Annahmen:
- Ein fester Anteil am Ranking. Angaben, wie viel Prozent die Core Web Vitals ausmachen, stammen nicht von Google. Google nennt kein Gewicht.
- Mehr Punkte, besseres Ranking. Die Punktzahl von 0 bis 100 in PageSpeed Insights stammt aus einem Labortest mit Lighthouse. Dass 100 Punkte besser ranken als 90, sagt Google nicht.
- Ein eigener Einfluss auf KI-Antworten. Für die Übersicht mit KI (AI Overviews) und den KI-Modus (AI Mode) nennt Google eine hohe Nutzerfreundlichkeit als eine der weiterhin sinnvollen SEO-Grundlagen, ohne Grenzwerte (Google Search Central (externe Website)). Microsofts Richtlinien für Bing und Copilot erwähnen weder Core Web Vitals noch Ladezeiten (Bing Webmaster Guidelines (externe Website), Stand 08.11.2026). Wie Google die Quellen für die Übersicht mit KI auswählt, erklärt unser Beitrag AI Overviews und KI-Modus.
Was heißt das für ein kleines Unternehmen?
Fehlt Ihre Website ganz in Google, helfen bessere Werte allein nicht. Dann geht es zuerst um die Indexierung. Die Prüfreihenfolge zeigt unser Ratgeber Warum wird meine Website nicht bei Google angezeigt?
Steht Ihre Website im Index, achten Sie zuerst auf die Werte für Smartphones. In Deutschland kamen im Oktober 2026 rund 60 % aller Seitenaufrufe von Smartphones.
Quelle: StatCounter, · Monatswert Oktober 2026, Kategorie Mobile: 60,21 %
Hat Ihre Website wenige Besuche, gibt es für sie womöglich keine Felddaten. Wie Google solche Seiten bewertet, beschreibt Google in seiner Dokumentation nicht. Nach unserer Einschätzung sind gute Laborwerte dann der beste verfügbare Anhaltspunkt.
Was unterscheidet Labordaten von Felddaten?
Felddaten stammen von echten Besuchen auf echten Geräten und zeigen, was Ihre Kundschaft erlebt. Labordaten entstehen in einem Test mit festgelegtem Gerät und Netz, etwa mit Lighthouse. Sie helfen, Ursachen zu finden und Änderungen vor der Veröffentlichung zu prüfen. Liegen beide vor, setzen Sie Ihre Prioritäten nach den Felddaten.
Felddaten liefert bei Google der Chrome UX Report. Er sammelt Messwerte von Chrome-Nutzern, die Nutzungsstatistiken senden und ihren Browserverlauf synchronisieren, am Computer und unter Android. Chrome auf dem iPhone, Apps mit eingebetteter Webansicht und andere Chromium-Browser wie Microsoft Edge liefern keine Daten (CrUX-Methodik (externe Website)). Aufgenommen werden nur öffentliche Seiten, die mit dem Status 200 antworten, kein noindex tragen und genug Besucher haben. Die Mindestzahl nennt Google nicht. PageSpeed Insights zeigt die Werte der vergangenen 28 Tage (Über PageSpeed Insights (externe Website)).
Labordaten misst Lighthouse, auch innerhalb von PageSpeed Insights. Für Smartphones bremst es den Prozessor des Testrechners um den Faktor vier, um ein Mittelklassegerät nachzubilden, und simuliert eine langsame Mobilverbindung mit 150 Millisekunden Latenz und 1,6 Megabit pro Sekunde (Lighthouse-Dokumentation zur Drosselung (externe Website)). Beim üblichen Seitentest gibt es keine Eingaben, deshalb misst Lighthouse dort kein INP. Ersatzweise misst es die Total Blocking Time (TBT): die Zeit nach dem ersten sichtbaren Inhalt, in der lange Aufgaben den Browser für Eingaben blockieren (web.dev zu TBT (externe Website)).
Die Leistungspunktzahl von 0 bis 100 berechnet Lighthouse 13.6.0 aus fünf Laborwerten: TBT zählt 30 %, LCP und CLS je 25 %, First Contentful Paint (FCP) und Speed Index je 10 % (Lighthouse 13.6.0 (externe Website)). Ab 90 Punkten gilt sie als gut (Chrome for Developers, Leistungspunktzahl (externe Website)). Gute Laborwerte bedeuten laut Google nicht zwingend, dass auch echte Besuche gute Werte haben. Weil die Punktzahl von Lauf zu Lauf schwankt, nehmen Sie den Median aus fünf Läufen. Er ist laut Lighthouse-Team doppelt so stabil wie ein einzelner Lauf (Lighthouse-Dokumentation zur Streuung (externe Website)).
Ein Labortest läuft auf einem Gerät, in einem Netz, von einem Ort aus. Im Feld liegen Dateien teils schon im Cache, und Besucher scrollen zu nachgeladenen Bildern ohne Maße, die ein Labortest nie erreicht. Deshalb fällt etwa CLS im Feld mal höher, mal niedriger aus als im Labor (web.dev, Labor und Feld (externe Website)).
Wie messen Sie die Core Web Vitals Ihrer Website?
Für eine einzelne Seite nutzen Sie PageSpeed Insights: Es zeigt die Felddaten der vergangenen 28 Tage und einen Labortest mit Lighthouse. Für die ganze Website nutzen Sie den Core Web Vitals-Bericht der Google Search Console. Fehlen Felddaten, bleiben Labortests und eine eigene Messung im Browser Ihrer Besucher.
| Werkzeug | Daten | Wofür | Grenzen |
|---|---|---|---|
| PageSpeed Insights | Felddaten aus CrUX und Labortest mit Lighthouse | eine Adresse prüfen; zeigt, ob die Seite die Prüfung besteht | ohne genug Besuche nur Werte der ganzen Website oder gar keine Felddaten |
| Google Search Console, Core Web Vitals-Bericht | Felddaten aus CrUX, nach Gruppen ähnlicher Seiten | Probleme der ganzen Website finden und ihre Behebung verfolgen | nur indexierte Seiten; eine Gruppe wird nach ihrer schwächsten Kennzahl bewertet |
| CrUX Vis | Felddaten im Wochenverlauf über mehrere Monate | Entwicklung nach einer Änderung verfolgen | nur Seiten und Websites mit genug Chrome-Besuchen |
| Chrome DevTools, Bereich Performance | Live-Werte im eigenen Browser, INP beim eigenen Klicken, Vergleich mit Felddaten | Ursachen eines Problems finden | eigenes Gerät und eigenes Netz |
| Lighthouse, im Browser oder in einer Prüfkette | Labortest | Änderungen vor der Veröffentlichung prüfen | beim Seitentest kein INP; Werte schwanken, deshalb Median aus fünf Läufen |
| Eigene Messung (Real User Monitoring, RUM) | Felddaten jedes Besuchs; LCP und INP auch aus Safari ab 26.2 und Firefox | Ursachen je Seite und Interaktion finden | braucht ein Skript auf Ihrer Website; CLS liefern nur Chromium-Browser |
Die Angaben stammen aus den Dokumentationen von PageSpeed Insights (externe Website), dem Core Web Vitals-Bericht (externe Website), CrUX Vis (externe Website) mit der CrUX History API (externe Website) und dem Performance-Bereich der DevTools (externe Website). Welche Browser eine eigene Messung unterstützen, steht in den Kompatibilitätsdaten von MDN (externe Website), Fassung 8.1.8 vom 02.11.2026.
So gehen Sie vor:
- Prüfen Sie Ihre wichtigste Seite in PageSpeed Insights (externe Website) für Mobilgeräte. Lesen Sie zuerst die Felddaten: Die Seite besteht, wenn alle drei Kennzahlen am 75. Perzentil gut sind. Fehlen Daten für INP, genügen gute Werte für LCP und CLS.
- Öffnen Sie in der Search Console den Core Web Vitals-Bericht. Beheben Sie zuerst, was als „Langsam“ markiert ist, danach die Gruppen mit den meisten oder den wichtigsten Adressen.
- Suchen Sie die Ursache im Labor: mit Lighthouse oder im Bereich Performance der Chrome DevTools.
- Ist ein Problem behoben, klicken Sie im Bericht auf „Tracking starten“. Die Search Console beobachtet die Felddaten dann vier Wochen lang.
Wie Sie einen Bericht von PageSpeed Insights Schritt für Schritt lesen und mit Lighthouse vergleichbar messen, zeigt unser Ratgeber Ladezeit messen.
Wie verbessern Sie LCP, INP und CLS?
Beginnen Sie mit der Kennzahl, die in den Felddaten am schlechtesten abschneidet. Bei LCP zählt, dass der Server schnell antwortet und das größte Element früh zu laden beginnt. Bei INP zählt, dass wenig JavaScript den Browser blockiert. Bei CLS zählt, dass Bilder, Einbettungen und Banner ihren Platz von Anfang an bekommen.
LCP ist die Kennzahl mit den wenigsten guten Werten. Im Chrome UX Report vom September 2026 hatten 68,3 % der erfassten Websites gute LCP-Werte, 81,7 % gute CLS- und 85,4 % gute INP-Werte; ein Gerät nennen die Release Notes dafür nicht.
Quelle: Chrome UX Report (Google) (externe Website), · Datensatz September 2026, 18.376.044 Websites
Bei LCP ist die Dateigröße des Bildes selten der Engpass. Die meisten Websites mit schlechtem LCP brauchen weniger als 10 % ihrer LCP-Zeit, um das Bild herunterzuladen. Oft vergeht mehr Zeit, bevor der Browser das Bild überhaupt anfordert (web.dev, wirksamste Maßnahmen (externe Website)). Wer nur das Bild verkleinert, verschiebt die gesparte Zeit manchmal bloß in einen anderen Teil der Ladezeit (web.dev, LCP optimieren (externe Website)).
Wo Sie ansetzen, um Ihre Website schneller und stabiler zu machen, zeigt die Tabelle. Sie stützt sich auf die Empfehlungen des Chrome-Teams und die Anleitungen zu LCP (externe Website), INP (externe Website) und CLS (externe Website).
| Kennzahl | Ursache | Was hilft |
|---|---|---|
| LCP | Das größte Bild wird spät gefunden, etwa weil ein Skript es nachlädt oder es mit loading="lazy" verzögert lädt | Bild als img mit src direkt im HTML einbinden, fetchpriority="high" setzen, loading="lazy" entfernen |
| LCP | Der Server antwortet langsam, Besucher kommen über Weiterleitungen | Seiten über ein CDN ausliefern und zwischenspeichern, Weiterleitungen vermeiden |
| LCP | Blockierendes CSS und JavaScript halten die Darstellung auf | CSS klein halten oder einbetten, Skripte verzögert laden, Seiten auf dem Server erzeugen |
| INP | Viel JavaScript: Aufgaben über 50 Millisekunden blockieren den Browser | unnötige Skripte und alte Tags im Tag-Manager entfernen, lange Aufgaben aufteilen |
| INP | Ein Einwilligungsbanner lädt beim Klick auf „Akzeptieren“ viele Skripte auf einmal | den Anbieter fragen, ob er die Arbeit nach dem Klick aufteilt |
| CLS | Bilder und Videos ohne Maße | width und height angeben oder den Platz mit aspect-ratio reservieren |
| CLS | Werbung, Karten, Videos und Banner beanspruchen nachträglich Platz | Platz mit min-height reservieren, Banner über den Inhalt legen statt ihn zu verschieben |
| CLS | Eine Webschrift läuft breiter oder schmaler als die Ersatzschrift | Ersatzschrift mit size-adjust anpassen, die wichtigste Schrift per preload laden |
| LCP und CLS | Die Seite kann nicht aus dem Back-Forward-Cache kommen, etwa wegen Cache-Control: no-store | solche Hindernisse entfernen; dann erscheint die Seite beim Zurückblättern sofort |
Bilder ohne Maße sind verbreitet: Im Juli 2025 hatten 62 % der Seiten auf Mobilgeräten mindestens ein solches Bild.
Quelle: HTTP Archive, Web Almanac 2025 (externe Website), , aktualisiert · Daten von Juli 2025
Wer nicht selbst programmiert, kann sich an zwei Faustregeln von Google halten: Eine Seite bleibt mit allen Ressourcen unter 500 KB, und auf Mobilgeräten lädt sie höchstens 50 Ressourcen (Search Console-Hilfe (externe Website)).
Ändern sich die Core Web Vitals 2027?
Nach heutigem Stand bleiben es dieselben drei Kennzahlen. Seit dem 13.10.2026 veröffentlicht Chrome zusätzlich Versuchsfassungen, die auch Seitenwechsel in Single-Page-Anwendungen erfassen. Chrome will sie im Mai 2027 aus dem Versuch holen, abhängig von Rückmeldungen; danach nutzt die Search Console die neuen Daten. Für klassische Websites erwartet das Chrome-Team keine Änderung.
Single-Page-Anwendungen laden beim Klick keine neue Seite vom Server. Sie tauschen Inhalt und Adresse per JavaScript aus. In den stabilen Werten rechnet der Chrome UX Report alle Eingaben und Verschiebungen einer solchen Sitzung der ersten Seite zu. Rund 70 % der Websites in CrUX haben kaum solche Seitenwechsel (web.dev, 13.10.2026 (externe Website)). Lädt Ihre Website bei jedem Klick eine neue Seite, erwartet das Chrome-Team keine Änderung Ihrer Werte.
Größere Änderungen kündigt Google vorher an, und stabile Kennzahlen ändern sich höchstens einmal im Jahr (web.dev, Web Vitals (externe Website)). Zuletzt hat Google am 12.03.2024 eine Kennzahl ausgetauscht: INP ersetzte First Input Delay (FID) (web.dev, 31.01.2024 (externe Website)).
Wie heißen Core Web Vitals auf Deutsch?
Eine feste deutsche Bezeichnung gibt es nicht. Google verwendet auch in deutschen Texten den englischen Begriff, etwa im Core Web Vitals-Bericht der Search Console. Sinngemäß sind es die zentralen Kennzahlen für die Nutzererfahrung einer Webseite.
Auch die Namen der drei Kennzahlen bleiben englisch. Sinngemäß bedeutet Largest Contentful Paint „Darstellung des größten Inhalts“, Interaction to Next Paint „Interaktion bis zur nächsten Darstellung“ und Cumulative Layout Shift „kumulierte Layoutverschiebung“; die Übersetzungen sind unsere. Den Oberbegriff page experience übersetzt Google mit „Nutzerfreundlichkeit von Seiten“. Im deutschen Bericht der Search Console heißen die Stufen „Gut“, „Optimierung erforderlich“ und „Langsam“ (Search Console-Hilfe (externe Website)).
Was unterscheidet Core Web Vitals von Lighthouse-Wert und Page Experience?
Core Web Vitals sind drei Kennzahlen aus Felddaten echter Besuche. Der Lighthouse-Wert ist eine Punktzahl von 0 bis 100 aus einem Labortest. Page Experience, bei Google auf Deutsch Nutzerfreundlichkeit von Seiten, ist der Oberbegriff: Dazu gehören neben den Core Web Vitals etwa HTTPS, eine gute Darstellung auf Mobilgeräten und der Verzicht auf aufdringliche Einblendungen (Interstitials).
Die Zahlen in der Spalte „Quellen“ sind die Nummern der Quellenliste am Ende des Beitrags.
| Begriff | Was es ist | Daten | Rolle in der Google-Suche | Quellen |
|---|---|---|---|---|
| Core Web Vitals (LCP, INP, CLS) | drei Kennzahlen für Laden, Reaktion und Stabilität | Felddaten, 75. Perzentil | von den Ranking-Systemen genutzt | 1, 6, 7 |
| Weitere Web Vitals, etwa Time to First Byte (TTFB) und First Contentful Paint (FCP) | Hilfskennzahlen, um Probleme mit LCP einzugrenzen | Feld und Labor | von Google nicht eigens genannt | 1, 13 |
| Lighthouse-Leistungswert | Punktzahl aus fünf gewichteten Laborwerten, darunter TBT als Ersatz für INP | Labor | laut Google ein Werkzeug, um Verbesserungen zu finden | 6, 16, 17 |
| Nutzerfreundlichkeit von Seiten (Page Experience) | Oberbegriff: Core Web Vitals, HTTPS, Mobildarstellung, wenig störende Werbung, keine aufdringlichen Interstitials, erkennbarer Hauptinhalt | je nach Aspekt | kein einzelnes Signal; Aspekte außer den Core Web Vitals wirken laut Google nicht direkt | 6 |
| First Input Delay (FID) | frühere Kennzahl nur für die erste Eingabe | Felddaten | seit 12.03.2024 durch INP ersetzt | 4, 33 |
Was gilt für Websites in Deutschland und der EU?
In Deutschland fehlt in den Felddaten ein großer Teil der Besuche: iPhones liefern keine Daten an den Chrome UX Report, am Desktop liefert sie nur Chrome. Bei Aufrufen aus Deutschland bestehen Websites die Prüfung häufiger als im weltweiten Mittel. Auf dem Smartphone fällt trotzdem fast ein Drittel durch.
Wer in den Felddaten fehlt: Im Oktober 2026 kamen in Deutschland 27,7 % der mobilen Seitenaufrufe von iPhones (iOS). Am Desktop lag Chrome bei 42,2 %, Edge bei 19,0 %, Firefox bei 17,1 % und Safari bei 11,9 %. Von diesen Browsern liefert nur Chrome Daten an CrUX.
Quelle: StatCounter (externe Website), · Monatswert Oktober 2026, Betriebssysteme mobil
Quelle: StatCounter, · Monatswert Oktober 2026, Browser am Desktop
Nutzt Ihre Kundschaft häufig iPhones, zeigen die Felddaten deshalb nur einen Ausschnitt. Eine eigene Messung erfasst LCP und INP inzwischen auch in Safari ab Version 26.2 und in Firefox ab Version 144, CLS dagegen nur in Chromium-Browsern wie Chrome und Edge (MDN, Fassung 8.1.8 (externe Website)).
Wie Websites in Deutschland abschneiden: Von den Websites, die Chrome-Nutzer in Deutschland im September 2026 oft genug aufriefen, erreichten auf dem Smartphone 69,2 % bei allen drei Kennzahlen gute Werte, am Desktop 73,0 %. Weltweit waren es 52,8 % und 60,8 %. Das Land bestimmt CrUX über die IP-Adresse der Nutzer (Chrome for Developers, Länder in CrUX (externe Website)). Gezählt sind also auch internationale Websites, die in Deutschland aufgerufen werden. Wie statische Websites und WordPress bei echten Besuchen abschneiden, zeigt unser Vergleich statische Website oder WordPress.
| Gerät und Gebiet | alle drei Werte gut |
|---|---|
| Smartphone, Deutschland | 69,2 % (406.207 von 586.975) |
| Smartphone, weltweit | 52,8 % (4.522.203 von 8.569.446) |
| Desktop, Deutschland | 73,0 % (147.692 von 202.380) |
| Desktop, weltweit | 60,8 % (3.280.280 von 5.391.031) |
Quelle: HTTP Archive, Core Web Vitals Technology Report (externe Website), · Datenstand September 2026, 586.975 Websites mobil, 202.380 am Desktop
Einwilligungsbanner: Banner zur Einwilligung in Cookies sind laut web.dev eine sehr häufige Ursache für Layoutverschiebungen, vor allem oben auf der Seite. Auf Smartphones kann ein Banner mit viel Text sogar das LCP-Element sein. Zeigt Ihre Website ein solches Banner, legen Sie es als Fußleiste oder Dialog über den Inhalt, statt den Inhalt nach unten zu schieben (web.dev, Cookie-Hinweise (externe Website)). Das ist eine technische Einordnung. Ob Ihre Website ein Banner braucht, klärt im Zweifel eine Anwältin oder ein Anwalt.
Aus der Praxis: So haben wir datafalke.de für LCP, INP und CLS gebaut
Regelmäßige Messwerte dieser Website nennen wir erst im Messprotokoll. Was wir für jede Kennzahl gebaut haben, können Sie aber schon an den ausgelieferten Seiten nachprüfen. Die Tabelle beschreibt den Stand vom 08.11.2026, geprüft an der Startseite und an den Seiten zur Website-Entwicklung, zur Methode und zu GEO (Generative Engine Optimization).
| Kennzahl | Was wir gebaut haben | So prüfen Sie es |
|---|---|---|
| LCP | Die geprüften Seiten binden weder Bilddateien noch Hintergrundbilder ein. Icons und Piktogramme stehen als SVG im HTML. Das größte Element ist Text. Eine Schriftdatei lädt per preload. CSS und Schriften darf der Browser ein Jahr lang zwischenspeichern. | Quelltext der Seite; Kopfzeile Cache-Control einer CSS-Datei: max-age=31536000, immutable |
| INP | Keine Seite lädt JavaScript. Die Kopfzeile Content-Security-Policy verbietet Skripte (script-src 'none'). Das Kontaktformular verarbeitet ein Programm auf dem Server. | Kopfzeilen der Seite im Bereich Network der DevTools |
| CLS | Wir verzichten auf Einbettungen, Werbung und ein Einwilligungsbanner: Die Website setzt keine Cookies und lädt nichts von Drittanbietern. Die Ersatzschrift Arial ist mit size-adjust und weiteren Angaben an die Maße unserer Webschrift angepasst, damit sich Text beim Wechsel der Schrift möglichst wenig verschiebt. | @font-face-Regeln im Quelltext; Bereich Network: nur Anfragen an datafalke.de |
Im Labor misst unsere Prüfkette festgelegte Seiten mit Lighthouse, jeweils fünfmal, und wertet den Median aus. Sie meldet einen Fehler, wenn eine der folgenden Grenzen überschritten wird. Zusätzlich bricht die Prüfung ab, wenn Lighthouse ein Bild als LCP-Element meldet.
"numberOfRuns": 5
"largest-contentful-paint": [
"error",
{ "maxNumericValue": 2000, "aggregationMethod": "median" }
],
"cumulative-layout-shift": [
"error",
{ "maxNumericValue": 0.05, "aggregationMethod": "median" }
],
"total-blocking-time": ["error", { "maxNumericValue": 100, "aggregationMethod": "median" }],
"resource-summary:script:size": ["error", { "maxNumericValue": 0 }],
"resource-summary:third-party:count": ["error", { "maxNumericValue": 0 }],Für echte Besuche haben wir uns strengere Ziele gesetzt, als Google für gute Werte nennt: höchstens 2,0 Sekunden für LCP, 150 Millisekunden für INP und 0,05 für CLS am 75. Perzentil. Ob wir sie erreichen, zeigen erst Felddaten. Wir veröffentlichen sie im Messprotokoll, sobald der Chrome UX Report Werte für datafalke.de ausweist. Welche Technik hinter der Website steht, beschreibt unser Kolophon.
So übertragen Sie das auf Ihre Website: Finden Sie in PageSpeed Insights oder in den DevTools heraus, welches Element bei Ihnen das LCP-Element ist. Ist es ein Bild, prüfen Sie, ob es direkt im HTML steht und ohne Verzögerung lädt. Zählen Sie danach im Bereich Network die Anfragen an fremde Server und prüfen Sie bei jeder, ob Sie sie brauchen. Inhalte von Drittanbietern belasten die Leistung laut web.dev in der Regel stärker als eigene (web.dev, Cookie-Hinweise (externe Website)).
Zum Messprotokoll