Modul 3 hat deine Website betriebsfähig gemacht. Ab hier geht es darum, wie gut sie sich für die Menschen anfühlt, die sie benutzen. Genau dafür gibt es die Core Web Vitals, und diese Lektion bringt dir bei, die drei Werte zu lesen und einzuordnen, nicht sie zu programmieren.
Kurzantwort
Was sind die Core Web Vitals?
Die Core Web Vitals sind drei Messwerte, mit denen Google das Nutzungserlebnis einer Seite beziffert: LCP für das Ladeerlebnis, INP für die Reaktionsfähigkeit, CLS für die visuelle Stabilität. Gemessen wird an echten Besuchern, nicht in einem Testlauf.
Entscheidend ist eine Sache, die fast überall fehlt: Dein Wert ist nicht dein Durchschnitt, sondern der Wert, den drei von vier Seitenaufrufen erreichen.
📌 Für wen ist das relevant: Für alle, die eine Website betreiben und mit einem Dienstleister über deren Geschwindigkeit sprechen, ohne selbst zu programmieren.
- Drei Metriken, Stand August 2026: LCP, INP und CLS
- Gut heißt: 2,5 Sekunden oder weniger, 200 Millisekunden oder weniger, 0,1 oder weniger
- Zwei Google-Werkzeuge können zur selben Seite verschiedene Zahlen zeigen, ohne dass eines falsch liegt
Das lernst du in dieser Lektion
Du weißt, was LCP, INP und CLS messen und ab welchem Wert es eng wird.
Du kannst die Werte deiner eigenen Seite in PageSpeed Insights nachschlagen und richtig deuten, statt sie für Ladezeiten zu halten.
Du verstehst, warum PageSpeed Insights und die Search Console sich widersprechen können.
Du erkennst überholte Ratgeber und übertriebene Versprechen an konkreten Merkmalen.
Inhalt
01 ·
Die drei Werte, um die es geht
Stand August 2026 bestehen die Core Web Vitals aus genau drei Metriken. Das Chrome-Team führt LCP, INP und CLS jeweils mit dem Status “Stable”, und die Google-Search-Dokumentation nennt aus der Suchperspektive dieselben drei mit denselben Zahlen. Ein Rahmensatz vorweg, damit du weißt, worauf du dich stützt: Alle Schwellen und Zitate dieser Lektion stammen aus Googles eigener Dokumentation, Stand August 2026, und wo eine Zahl von woanders kommt, steht es dabei.
| Metrik | Was sie misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP Largest Contentful Paint |
Wann das größte sichtbare Element im ersten Bildschirmausschnitt dasteht | 2,5 Sekunden oder weniger | über 2,5 bis 4,0 Sekunden | über 4,0 Sekunden |
| INP Interaction to Next Paint |
Wie schnell die Seite sichtbar auf Klicks und Eingaben reagiert | 200 Millisekunden oder weniger | über 200 bis 500 Millisekunden | über 500 Millisekunden |
| CLS Cumulative Layout Shift |
Wie stark sichtbare Elemente unerwartet verrutschen | 0,1 oder weniger | über 0,1 bis 0,25 | über 0,25 |
Bei LCP steckt der häufigste Denkfehler in der Übersetzung. LCP misst nicht, wann die Seite fertig geladen ist, sondern die Renderzeit des größten Bildes, Textblocks oder Videos im sichtbaren Bereich, in der Praxis meist das Titelbild oder die Hauptüberschrift.
Bei INP zählen Klicks, Tipper und Tastendrücke, zu den übrigen Interaktionen schreibt Google wörtlich: “Users may also interact with the page in other ways, like hovering, zooming, or scrolling. These interactions are not observed for the purposes of INP.” Ein ruckelndes Scrollverhalten fließt also nicht direkt in den INP-Wert ein, auch wenn beides oft dieselbe Ursache hat.
CLS misst als einzige keine Zeit. Der Wert wird ohne Einheit angegeben und beschreibt die größte zusammenhängende Serie unerwarteter Verschiebungen.
Zwei Einordnungen gehören dazu. Als “bestanden” gilt eine Seite in der gängigen Auswertungspraxis, wenn alle drei Werte grün sind. Und ausgewiesen wird getrennt für Mobil und Desktop.
Ein grünes Desktop-Ergebnis sagt nichts über das Handy. Die mobile Fassung ist zugleich die, anhand derer Google indexiert und rankt (siehe Lektion zu Responsive Design).
💡 Praxis-Tipp
Schlag deine eigenen Werte jetzt nach, bevor du weiterliest. Öffne pagespeed.web.dev und gib die Adresse deiner Startseite ein. Notiere aus dem oberen Felddaten-Block die drei Werte für LCP, INP und CLS, einmal für Mobil und einmal für Desktop.
Leg die sechs Zahlen neben die Tabelle oben und markiere die Farbe jedes Werts. Das ist dein Arbeitsmaterial für den Rest der Lektion, und steht dort “nicht genügend Daten”, ist auch das ein Ergebnis, das Sektion 03 erklärt.
02 ·
Das 75. Perzentil: dein Wert ist nicht dein Durchschnitt
Das hier ist der wichtigste Absatz der Lektion, denn ohne ihn wird jede weitere Zahl falsch gelesen. Alle drei Metrik-Seiten enthalten denselben Satz:
“A good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.”
Bewertet wird also nicht der Mittelwert, sondern der Wert, den drei von vier Seitenaufrufen erreichen. Steht dein LCP-Wert bei 2,8 Sekunden, heißt das: Bei einem Viertel der Aufrufe dauerte es länger, bei drei Vierteln ging es schneller.
Wie du einen Core-Web-Vitals-Wert liest
Drei Sätze, die aus einer Zahl eine Aussage machen (Stand 08/2026)
Bewertet wird das 75. Perzentil der Seitenaufrufe. Der angezeigte Wert ist der, den drei von vier Aufrufen mindestens erreichen.
Ein grüner Wert sagt: Bei mindestens 75 Prozent der Aufrufe war es gut. Über das langsamste Viertel sagt er nichts.
Ein Aufruf im schlechten Netz oder auf einem alten Gerät verdirbt die Bewertung nicht. Google nennt den Schutz vor Ausreißern ausdrücklich als eines von zwei Kriterien für die Wahl dieses Perzentils.
Gezählt werden Seitenaufrufe, nicht Personen. Ein Besucher, der zehn Seiten ansieht, geht zehnfach in die Auswertung ein.
Quellen: web.dev, Metrik-Seiten zu LCP, INP und CLS (identischer Perzentil-Satz) sowie web.dev, “Defining the Core Web Vitals metrics thresholds”, abgerufen 16.08.2026 – Stand 08/2026, eigene didaktische Darstellung, Ostend Digital.
Schaubild: Wie ein Core-Web-Vitals-Wert zu lesen ist – eigene Darstellung nach den Google-Metrikseiten, Ostend Digital, Stand 08/2026.
Die Wahl begründet Google so:
“The 75th percentile was chosen based on two criteria. First, the percentile should ensure that a majority of visits to a page or site experienced the target level of performance. Second, the value at the chosen percentile shouldn’t be overly impacted by outliers.”
Beide Kriterien ziehen in verschiedene Richtungen, und genau das ist der Punkt. Ein Perzentil von 95 würde extrem langsame Einzelaufrufe zum Maßstab machen, ein Mittelwert ein schlechtes Viertel unsichtbar.
Sprich den Merksatz jetzt einmal mit deinem eigenen LCP-Wert von eben: “Bei einem Viertel der Aufrufe dauerte es länger als …”. Wenn dir dieser Satz leicht über die Lippen geht, hast du das Perzentil verstanden und wirst den Wert nie wieder für eine Ladezeit halten.
💡 Merke
Ein knapp roter Wert ist selten ein technischer Totalschaden. Er sagt zunächst nur, dass mehr als ein Viertel deiner Seitenaufrufe über der Schwelle liegt.
Das ist eine andere Nachricht als “die Seite ist langsam”. Häufig ist ein bestimmter Seitentyp, ein bestimmtes Gerät oder eine Verbindungsart betroffen.
Die erste sinnvolle Frage lautet deshalb nicht “was optimieren wir”, sondern “welches Viertel ist das eigentlich”.
03 ·
Warum PageSpeed Insights und die Search Console sich widersprechen
An dieser Frage bleiben die meisten Gespräche über Core Web Vitals hängen. Ein Werkzeug zeigt 38 Punkte in Rot, das andere meldet für dieselbe Seite grüne Werte, und beide kommen von Google. Beide haben recht, weil sie verschiedene Dinge zeigen: Dahinter steckt der Unterschied zwischen Felddaten und Labordaten.
Felddaten sind anonymisierte Messwerte echter Chrome-Nutzer, die deine Seite aufgerufen haben. Sie stammen aus dem Chrome User Experience Report, kurz CrUX.
Labordaten sind das Gegenteil: ein einziger, künstlich erzeugter Aufruf unter festgelegten Bedingungen. Das Werkzeug heißt Lighthouse, die simulierte Umgebung beschreibt Google als Mittelklasse-Gerät (Moto G4) im Mobilfunknetz für Mobil und emulierten Desktop mit Kabelverbindung.
Googles eigene Gegenüberstellung:
“The field data is a historical report about how a particular URL has performed, and represents anonymized performance data from users in the real-world on a variety of devices and network conditions. The lab data is based on a simulated load of a page on a single device and fixed set of network conditions.”
Felddaten sind also eine Rückschau auf viele echte Besuche, Labordaten ein einzelner Testlauf, jetzt gerade. Zwei verschiedene Fragen, nicht zwei Messungen derselben Sache.
Drei Anzeigen, drei verschiedene Aussagen
Was du in welchem Werkzeug tatsächlich vor dir hast (Stand 08/2026)
1 · Oben in PageSpeed
Felddaten aus CrUX
Echte Chrome-Nutzer, rollendes 28-Tage-Fenster. Enthält LCP, INP, CLS und FCP.
2 · Der Punktwert
Lighthouse-Labortest
Ein simulierter Aufruf, jetzt gerade. Fünf Labormetriken, davon drei ohne Core-Web-Vitals-Status. INP fehlt ganz.
3 · Search Console
Nur Felddaten
Dieselbe CrUX-Quelle, 28 Tage, aber nach Gruppen ähnlicher Seiten statt je URL.
Punktwert und Core-Web-Vitals-Bewertung stehen auf derselben Seite untereinander und sind trotzdem zwei verschiedene Dinge.
Quellen: Google for Developers, “About PageSpeed Insights”; Chrome for Developers, “Lighthouse performance scoring”; Google-Search-Console-Hilfe, Core-Web-Vitals-Bericht – alle abgerufen 16.08.2026. Stand 08/2026, eigene Darstellung, Ostend Digital.
Schaubild: Was PageSpeed Insights und die Search Console jeweils anzeigen – eigene Darstellung nach der Google-Dokumentation, Ostend Digital, Stand 08/2026.
Der Punktwert ist nicht die Core Web Vitals
Der bekannte Wert zwischen 0 und 100 ist der Lighthouse-Performance-Score, zusammengesetzt aus fünf Labormetriken mit fester Gewichtung (Lighthouse 10).
| Labormetrik | Gewicht | Core Web Vital? |
|---|---|---|
| Total Blocking Time (TBT) | 30 Prozent | Nein |
| Largest Contentful Paint (LCP) | 25 Prozent | Ja |
| Cumulative Layout Shift (CLS) | 25 Prozent | Ja |
| First Contentful Paint (FCP) | 10 Prozent | Nein |
| Speed Index | 10 Prozent | Nein |
Die schwerste Einzelposition ist TBT, und TBT ist kein Core Web Vital. INP taucht im Punktwert überhaupt nicht auf, weil ein Labortest nicht klickt. Ein Lighthouse-Wert von 100 bedeutet also nicht, dass du die Core Web Vitals bestanden hast, denn eine der drei Metriken fehlt in dieser Zahl.
Dazu kommt die Schwankung. Google schreibt selbst, ein großer Teil davon liege an veränderten Rahmenbedingungen und nicht an Lighthouse, und empfiehlt, Performance als Verteilung zu betrachten statt als einzelne Zahl.
Das rollende 28-Tage-Fenster
PageSpeed Insights nutzt den CrUX-Datensatz mit einem, wörtlich, “trailing 28-day collection period”, die Search-Console-Hilfe spricht von den Daten “in den letzten 28 Tagen”.
Wer heute optimiert, sieht morgen im Labortest ein Ergebnis, in den Felddaten aber nicht. “Wir haben doch etwas gemacht, warum ändert sich nichts” ist deshalb meist keine Frage der Maßnahme, sondern des Kalenders.
Wer überhaupt in den Felddaten landet
Nicht jeder Besucher zählt mit. Ein Nutzer fließt nur ein, wenn er alle vier Bedingungen der CrUX-Methodik erfüllt: aktivierte Nutzungsstatistiken, synchronisierter Browserverlauf, keine Sync-Passphrase und eine unterstützte Plattform, also Desktop-Chrome oder Chrome unter Android.
Nicht enthalten sind Chrome auf iOS, Apps mit eingebettetem Browser und andere Chromium-Browser. Safari-, Firefox- und sämtliche iPhone-Nutzer tauchen in deinen Core Web Vitals also gar nicht auf. Das macht die Daten nicht unbrauchbar, es gibt ihnen nur eine bestimmte Grundgesamtheit.
Auch Seiten müssen öffentlich auffindbar und ausreichend populär sein. Genau hier entsteht der häufigste Frust kleiner Websites, denn “nicht genügend Daten” ist kein Fehler, sondern diese Popularitätsschwelle. Eine Zahl nennt Google dafür nicht.
Bleibt die Frage, welcher Wert der wichtigere ist. Googles Antwort ist eindeutig: Priorisiere nach den Felddaten, denn sie bilden ab, was echte Nutzer erleben.
Prüf das gleich an deinem eigenen Ergebnis von vorhin. Der obere Block mit LCP, INP und CLS sind deine Felddaten, der Punktwert darunter ist der Labortest, und ab jetzt liest du beide getrennt: oben die Bewertung, unten die Diagnose.
04 ·
FID: die Metrik, die es nicht mehr gibt
Bei der Recherche zu diesem Thema wirst du auf eine vierte Abkürzung stoßen: FID, First Input Delay. Sie gehörte einmal zu den Core Web Vitals und tut es nicht mehr.
Seit März 2024 ist INP an ihre Stelle getreten. Im September 2024 hat Chrome die Unterstützung endgültig beendet, wörtlich: “as of today FID is no longer supported in Chrome tools”. Zeigt ein Werkzeug dir heute einen FID-Wert, misst es also etwas, das Google nicht mehr auswertet.
Die Umstellung ist zugleich eine gute Probe darauf, ob eine Quelle aktuell ist. Sie ist über zwei Jahre her und betrifft eine von drei Metriken, trotzdem ist sie nicht überall angekommen: Eine im August 2026 abgerufene Ratgeberseite mit Aktualisierungsdatum 2025 führt FID weiterhin als aktuelle Metrik, ohne INP zu erwähnen.
💡 Praxis-Tipp
Prüf jeden Ratgeber zu diesem Thema mit einem Blick auf drei Buchstaben. Steht dort FID als aktuelle Metrik, ist der Text inhaltlich auf dem Stand vor März 2024, egal welches Datum oben drüber steht.
Dasselbe gilt für Angebote. Wer eine Optimierung “für LCP, FID und CLS” anbietet, arbeitet mit einem überholten Zielbild.
Ein Aktualisierungsdatum ist eine Behauptung über eine Datei, kein Aktualitätsbeweis. Die Gegenprobe geht schnell: Kommt INP vor, ist der Text in diesem Punkt aktuell.
Ist seither etwas Neues dazugekommen?
Nein. Die Datenquelle, aus der Google die Core Web Vitals bezieht, ist CrUX, und CrUX veröffentlicht zu jedem Datensatz Release-Notes, in denen eine neue Metrik zwangsläufig auftauchen müsste.
Dort ist bis zum aktuellen Datensatz, dem Juli 2026 vom 11.08.2026, keine neue Core-Web-Vitals-Metrik hinzugekommen, und keine bestehende hat ihren Status geändert. Es bleibt bei drei Werten, und genau die drei hast du eben notiert.
Angekündigt ist bislang nur, dass Google auch sogenannte Soft Navigations messen will, also Seitenwechsel innerhalb App-artiger Websites. Für eine typische WordPress- oder Baukasten-Website spielt das heute keine Rolle, und es ist ausdrücklich offen: Google formuliert die Absicht, hält im selben Text aber fest, dass die Art der Berichterstattung in CrUX “still to be determined” ist.
05 ·
Womit du misst, und was die Werkzeuge nicht können
Für die Zielgruppe dieser Lektion reichen zwei Werkzeuge, beide kostenlos und ohne technische Kenntnisse bedienbar.
| Werkzeug | Datenart | Kann | Kann nicht |
|---|---|---|---|
| PageSpeed Insights | Feld und Labor nebeneinander | Jede öffentliche URL prüfen, ohne Login, auch die eines Wettbewerbers | Keine Historie, keine Übersicht über die ganze Website |
| Search Console | Nur Feld | Alle eigenen URLs, nach Problemgruppen sortiert, mit Verlauf | Nur die eigene, bestätigte Property. Sagt nicht, woran es liegt |
| Lighthouse (in Chrome) | Nur Labor | Konkrete Verbesserungsvorschläge zur eigenen Seite | Misst kein INP. Ein einzelner Lauf, der schwankt |
PageSpeed Insights beantwortet “wie steht diese eine Seite da”, die Search Console “welcher Seitentyp hat flächendeckend ein Problem”. Sie zeigt dabei nicht jede URL, sondern fasst, wörtlich, URLs “in Seiten gruppiert, bei denen die Nutzerfreundlichkeit jeweils ähnlich ist”.
Daraus folgt der Ablauf für deinen ersten vollständigen Check, den du direkt heute durchgehen kannst:
- Drei Seiten in PageSpeed Insights prüfen: Startseite, wichtigste Leistungsseite, Kontaktseite. Dabei nur den oberen Felddaten-Block ansehen.
- Search Console öffnen, Bericht Core Web Vitals, getrennt für Mobil und Desktop.
- Bei “nicht genügend Daten” ruhig bleiben. Dann ist der Labortest die einzige Information, und der ist eine Diagnose, keine Bewertung.
- Vier Wochen warten, bevor du eine Änderung an den Felddaten beurteilst.
Experten-Tipp aus der Agentur
Wenn dir jemand eine Optimierung anbietet und dabei einen Screenshot mit einem roten Punktwert zeigt, stell eine einzige Rückfrage: Wie sehen die Felddaten aus?
Damit trennst du in einem Satz die beiden Fälle. Ein roter Punktwert bei grünen Felddaten ist ein Diagnosehinweis, rote Felddaten sind ein echter Befund.
Und lass dir vor der Beauftragung sagen, welcher der drei Werte gemeint ist und auf welchem Gerätetyp. “Die Seite ist zu langsam” ist keine Diagnose, sondern ein Gefühl.
Pascal Cabitza
Geschäftsführer Ostend Digital
06 ·
Was die Werte in der Praxis drückt
Diese Lektion erklärt Messung und Einordnung, die Umsetzung ist Thema der nächsten Lektion zum Optimieren der Website. Ein Grundverständnis der Ursachen gehört trotzdem hierher.
Bei LCP nennt Google langsame Server-Antwortzeiten, render-blockierende Stylesheets und Skripte sowie nicht optimierte Dateien. Vor der Schnelllösung warnt derselbe Leitfaden ausdrücklich: “It’s rare that a quick fix to a single part of a page will result in a meaningful improvement to LCP.”
Bei CLS ist Googles Ursachenliste kurz und wörtlich: Bilder ohne Größenangabe, Werbung und Einbettungen ohne Größenangabe, nachträglich eingefügte Inhalte ohne Größenangabe sowie Web-Schriften. CLS ist damit die einzige Metrik, die du ohne Werkzeug selbst erleben kannst: Lade deine Startseite auf dem Handy neu und schau zu, ob etwas springt. Den Punkt Schriften löst du dauerhaft im eigenen Designsystem für Websites statt Seite für Seite.
Bei INP nennt Google unter anderem lange blockierende Aufgaben und große DOM-Größen, also sehr viele verschachtelte Elemente im Seitenaufbau. Der letzte Punkt trifft viele Websites, ohne dass es jemand ahnt, denn Seitenbaukästen erzeugen für ein optisch schlichtes Layout oft sehr viele davon.
Der deutsche Sonderfall: das Consent-Banner
Für deutsche Websites ist das Einwilligungs-Banner keine Option, sondern Pflicht. Google widmet dem Thema eine eigene Dokumentationsseite mit erfreulich differenzierten Aussagen.
Zu INP heißt es wörtlich: “Cookie notices can often be a cause for high INP as they typically add a lot of third-party scripts when accepted.” Kritisch ist demnach der Klick auf “Akzeptieren”, weil dabei viele fremde Skripte auf einmal nachgeladen werden. Zu CLS ist die Aussage ebenso deutlich: “Cookie consent notices are a very common source of layout shifts.”
Beim LCP sagt Google dagegen das Gegenteil dessen, was man oft liest. Die meisten Banner seien recht klein und enthielten deshalb typischerweise nicht das LCP-Element, mit der Einschränkung, dass es bei textlastigen Bannern auf Mobilgeräten doch vorkommen kann.
💡 Merke
Das Banner ruiniert nicht pauschal deine Core Web Vitals. Belegt ist der Einfluss auf INP und CLS, beim LCP sagt Google, dass Banner typischerweise nicht das größte Element sind.
Die richtige Konsequenz ist nicht, das Banner wegzulassen. Rechtlich ist das keine Option, und technisch löst es das Problem auch nicht.
Sie ist eine Frage an deinen Anbieter. Google hält fest, dass fremd eingebundene Banner mehr Einfluss auf die Performance haben als selbst gebaute, und die Wahl des Anbieters kannst du selbst treffen.
Werte verschlechtern sich außerdem schleichend, weshalb die laufende Wartung deiner Website und die Core Web Vitals dasselbe Thema sind.
07 ·
Der ehrliche Maßstab: was realistisch ist
Ein roter Wert fühlt sich an wie ein persönliches Versagen. Deshalb gehört hierher ein Vergleichsmaßstab mit Quelle: der Web Almanac von HTTP Archive, ein Open-Source-Projekt und kein Google-Dokument, dessen Core-Web-Vitals-Daten aber aus CrUX stammen.
| Auswertung | Anteil “gut” | Quelle und Kontext |
|---|---|---|
| Alle drei Werte gut, mobil | 48 Prozent | Kapitel Performance, Messmonat Juli 2025, Millionen von Websites |
| Alle drei Werte gut, Desktop | 56 Prozent | Dieselbe Auswertung |
| WordPress-Origins, mobil | 45 Prozent | Kapitel CMS, veröffentlicht 15.01.2026 |
| Duda-Origins, mobil | 85 Prozent | Dieselbe Auswertung, oberer Wert des dortigen Systemvergleichs |
Die erste Zeile ist die wichtigste. Etwa jede zweite Website besteht die Core Web Vitals auf dem Handy nicht, das ist keine Randgruppe, sondern die Hälfte des ausgewerteten Webs. Liegt deine Seite im gelben Bereich, bist du nicht der Ausreißer, sondern im Mittelfeld.
Der Wert von 45 Prozent für WordPress-Origins verlangt drei Einschränkungen. Erstens sind das Anteile von Origins, nicht von Seiten, eine große und eine kleine Website zählen also gleich. Zweitens ist der Vergleich nicht kausal: Dass die Gesamtheit der WordPress-Websites schlechter abschneidet, heißt weder, dass WordPress langsam ist, noch dass deine Seite zu 45 Prozent gut wäre.
Naheliegend erklären lässt sich der Abstand mit der Offenheit des Systems, das jedes Theme, jedes Plugin und jeden Hoster zulässt, während geschlossene Baukästen Hosting und Auslieferung selbst kontrollieren. Drittens folgt daraus keine Empfehlung, das System zu wechseln, denn aus einer Verteilung über Millionen Websites lässt sich für den Einzelfall nichts ableiten.
Was WordPress ausmacht, steht in Lektion zu den WordPress-Grundlagen. Eine eigene Bestehensquote für Deutschland weist der Web Almanac nicht aus, rechne also mit dem weltweiten Maßstab.
💡 Merke
Das Ziel sind grüne Felddaten, nicht 100 Punkte im Labortest. Googles Schwellen sind ausdrücklich so gewählt, dass sie für bestehende Inhalte im Web erreichbar sind.
Ein Punktwert von 100 ist dagegen keine Zielgröße. Er enthält zwei Metriken, die keine Core Web Vitals sind, und eine der drei fehlt darin ganz.
Wer dir eine Punktzahl verkauft, verkauft dir die falsche Zielgröße. Frag nach den drei Felddaten-Werten für beide Gerätetypen, Mobil zuerst.
Damit hast du alles für die Entscheidung beisammen. Leg deine sechs notierten Werte ein letztes Mal neben die Schwellentabelle aus Sektion 01 und schau zuerst auf Mobil. Sind die mobilen Felddaten grün, reicht es, die Werte im Rahmen der Wartung im Blick zu behalten, und steht dort Gelb oder Rot, ist die nächste Lektion zum Optimieren dein konkreter nächster Schritt.
08 ·
Was Google zum Ranking wirklich sagt
Zu kaum einem Thema kursieren zwei so gegensätzliche Übertreibungen: Die eine erklärt die Core Web Vitals zum wichtigsten Rankingfaktor überhaupt, die andere für bedeutungslos. Google selbst hat sich dazu geäußert, auf Deutsch, in der eigenen Dokumentation.
“Es gibt kein einzelnes Signal. Unsere Ranking-Systeme berücksichtigen eine Reihe von Signalen, die auf die Nutzerfreundlichkeit von Seiten schließen lassen.”
“Core Web Vitals werden von unseren Rankingsystemen genutzt.”
“Die Google Suche versucht immer, die relevantesten Inhalte anzuzeigen, selbst wenn die Nutzerfreundlichkeit von Seiten in mancher Hinsicht unterdurchschnittlich ausfällt.”
Diese drei Sätze stehen nebeneinander auf derselben Seite. Der zweite widerlegt die Verharmloser, der erste und der dritte die Übertreiber. Ergänzend heißt es, für viele Suchanfragen gebe es reichlich hilfreiche Inhalte, und dann könne eine gute Nutzererfahrung zum Erfolg beitragen.
Gegen die Ranking-Garantie hilft dieser Satz:
“Keep in mind that getting good results in reports like Search Console’s Core Web Vitals report or third-party tools doesn’t guarantee that your pages will rank at the top of Google Search results.”
Bemerkenswert ist außerdem die Begründung der Empfehlung: gutes Abschneiden in der Suche “and to ensure a great user experience generally”. Beides steht dort nebeneinander, nicht das Ranking allein.
ℹ️ Die ehrliche Übersetzung
So übersetzen wir diese Zitate für die Praxis, als Einordnung von uns, nicht von Google: Die Core Web Vitals sind ein Faktor unter vielen, nicht der Faktor, und sie ersetzen keine Relevanz.
Wer die schlechtere Antwort auf die Suchfrage hat, gewinnt nicht durch eine schnellere Ladezeit. Ihr Hebel liegt dort, wo mehrere Seiten inhaltlich ähnlich gut sind, also im umkämpften Mittelfeld.
Der beste Grund, sich zu kümmern, liegt ohnehin daneben. Eine Seite, die schnell erscheint, sofort reagiert und beim Lesen nicht springt, verliert weniger Besucher, unabhängig von jeder Platzierung.
09 ·
💡 Recap
Die Core Web Vitals in 30 Sekunden:
- Drei Metriken, Stand August 2026: LCP, INP und CLS. Gut heißt 2,5 Sekunden oder weniger, 200 Millisekunden oder weniger und 0,1 oder weniger
- Dein Wert ist nicht dein Durchschnitt. Bewertet wird das 75. Perzentil der Seitenaufrufe, das langsamste Viertel zählt für die Bewertung nicht mit
- Feld und Labor beantworten verschiedene Fragen. Felddaten sind eine Rückschau auf echte Chrome-Nutzer über 28 Tage, der Labortest ein einzelner simulierter Aufruf jetzt gerade. Sein Punktwert besteht aus fünf Labormetriken, die schwerste davon ist kein Core Web Vital, und INP kommt darin gar nicht vor
- FID gehört seit März 2024 der Vergangenheit an. Ein Ratgeber, der FID als aktuelle Metrik führt, ist überholt, unabhängig vom Aktualisierungsdatum
- Nicht jeder Besucher zählt mit: In den Felddaten landen nur einwilligende Chrome-Nutzer auf Desktop und Android. Kleine Seiten bekommen oft gar keine Felddaten
- Beim Ranking bleibt Google differenziert: “Core Web Vitals werden von unseren Rankingsystemen genutzt”, zugleich “es gibt kein einzelnes Signal”, und gute Werte garantieren keine Platzierung
10 ·
Selbstcheck: kannst du das beantworten?
Dein LCP-Wert liegt bei 3,1 Sekunden. Wie erklärst du deinem Team, was das bedeutet?
Nicht als “unsere Seite braucht 3,1 Sekunden”. Bewertet wird das 75. Perzentil der Seitenaufrufe, also der Wert, den drei von vier Aufrufen erreichen.
Richtig ist: Bei einem Viertel der Aufrufe dauerte es länger als 3,1 Sekunden, bis das größte sichtbare Element dastand. Der Wert liegt damit im verbesserungswürdigen Bereich zwischen 2,5 und 4,0 Sekunden.
Die nächste sinnvolle Frage ist, welches Viertel das ist, also welcher Gerätetyp oder Seitentyp betroffen ist.
PageSpeed Insights zeigt 42 Punkte, die Search Console meldet für dieselbe Seite grün. Wer hat recht?
Beide. Die 42 Punkte sind der Lighthouse-Labortest, also ein einzelner simulierter Aufruf auf einem Mittelklasse-Gerät im Mobilfunknetz.
Die Search Console zeigt dagegen ausschließlich Felddaten aus CrUX über die letzten 28 Tage. Das sind zwei verschiedene Messungen, keine widersprüchlichen Ergebnisse.
Für die Priorisierung sind die Felddaten der Bezugspunkt, weil sie abbilden, was Besucher tatsächlich erleben.
Ein Ratgeber aus dem laufenden Jahr erklärt LCP, FID und CLS. Was schließt du daraus?
Dass der Text inhaltlich auf dem Stand vor März 2024 ist, unabhängig vom Datum darüber. Seit März 2024 ist INP an die Stelle von FID getreten, im September 2024 hat Chrome die Unterstützung in seinen Werkzeugen beendet.
Das ist kein Einzelfall. Eine im August 2026 abgerufene Ratgeberseite mit Aktualisierungsdatum 2025 führt FID weiterhin als aktuelle Metrik, ohne INP zu erwähnen.
Praktische Konsequenz: Prüf, ob INP vorkommt und ob die genannten Schwellenwerte zu den aktuellen passen.
Alle Lektionen des Webdesign- und CRO-Kurses im Überblick →
Quellen und Stand (14 Einträge)
- web.dev, “Web Vitals” (Seitenstand laut eigener Angabe 31.10.2024, abgerufen 16.08.2026) – Lifecycle-Status “Stable” für LCP, INP und CLS; Feldmessbarkeit als Definitionsmerkmal der Core Web Vitals; Einordnung von Total Blocking Time als Labormetrik außerhalb des Sets. Quellentyp: Herstellerdokumentation (web.dev wird vom Chrome-Team betrieben)
- web.dev, “Largest Contentful Paint (LCP)” (Stand 04.09.2025, abgerufen 16.08.2026) – Definition als Renderzeit des größten Bildes, Textblocks oder Videos im sichtbaren Bereich; Schwellen 2,5 und 4,0 Sekunden; Perzentil-Satz
- web.dev, “Interaction to Next Paint (INP)” (Stand 02.09.2025, abgerufen 16.08.2026) – Definition; gezählte Interaktionen (Maus, Touch, Tastatur); wörtlicher Ausschluss von Hovern, Zoomen und Scrollen; Schwellen 200 und 500 Millisekunden; Perzentil-Satz
- web.dev, “Cumulative Layout Shift (CLS)” (Stand 12.04.2023, abgerufen 16.08.2026) – Definition als größte Serie unerwarteter Layout-Verschiebungen; Schwellen 0,1 und 0,25; Werte durchgehend ohne Einheit angegeben; Perzentil-Satz. Hinweis: älteste der drei Metrikseiten, die Schwellen werden von der Search-Central-Seite (Stand 10.12.2025) bestätigt
- web.dev, “Defining the Core Web Vitals metrics thresholds” (Stand 07.05.2025, abgerufen 16.08.2026) – wörtliche Begründung der Wahl des 75. Perzentils (Mehrheit der Besuche, Schutz vor Ausreißern); Kriterium der Erreichbarkeit für bestehende Web-Inhalte
- web.dev-Blog, “Chrome ends support for First Input Delay” (10.09.2024, abgerufen 16.08.2026) – wörtlich “as of today FID is no longer supported in Chrome tools”; Liste der Werkzeuge und Schnittstellen, aus denen FID entfernt wurde. Ergänzend web.dev-Blog, “Interaction to Next Paint becomes a Core Web Vital on March 12” (Titel und Datum belegt, Volltext für diese Lektion nicht abgerufen). Aus diesem Grund wird hier nur “seit März 2024” geschrieben und kein Tagesdatum
- Google Search Central, “Understanding Core Web Vitals and Google search results” (Stand 10.12.2025 UTC, abgerufen 16.08.2026) – dieselben drei Metriken und Schwellen aus der Suchperspektive; Empfehlung im Wortlaut “for success with Search and to ensure a great user experience generally”
- Google Search Central, “Nutzerfreundlichkeit von Seiten” (deutsche Fassung, Stand 18.12.2025 UTC) sowie die englische Fassung “Page experience” (Stand 10.12.2025 UTC), beide abgerufen 16.08.2026 – die deutschen Zitate “Es gibt kein einzelnes Signal …”, “Core Web Vitals werden von unseren Rankingsystemen genutzt” und “Die Google Suche versucht immer, die relevantesten Inhalte anzuzeigen …”; englisch die Aussagen zur fehlenden Ranking-Garantie und zu Aspekten jenseits der Core Web Vitals
- Google for Developers, “About PageSpeed Insights” (Stand 21.10.2024, abgerufen 16.08.2026) – Gegenüberstellung von Feld- und Labordaten im Wortlaut; gemeldete Felddaten-Metriken FCP, INP, LCP und CLS; rollendes 28-Tage-Fenster; simulierte Bedingungen (Moto G4 im Mobilfunknetz, emulierter Desktop mit Kabelverbindung)
- Chrome for Developers, “Lighthouse performance scoring” (abgerufen 16.08.2026) – Gewichtung des Performance-Scores in Lighthouse 10 (TBT 30 Prozent, LCP 25 Prozent, CLS 25 Prozent, FCP 10 Prozent, Speed Index 10 Prozent); Aussage zur Schwankung und Empfehlung, Performance als Verteilung zu betrachten. Hinweis: Die Seite wies ein unplausibles Aktualisierungsdatum aus, deshalb wird hier nur die Lighthouse-Version genannt und kein Datum behauptet
- Google-Search-Console-Hilfe, “Core Web Vitals-Bericht” (deutsch, abgerufen 16.08.2026) – Datenherkunft aus CrUX; Zeitfenster “in den letzten 28 Tagen”; Gruppierung von URLs nach ähnlicher Nutzerfreundlichkeit; Ausschluss von URL-Gruppen ohne Mindestmenge an Berichtsdaten
- Chrome for Developers: “Chrome UX Report” (Stand 08.02.2024), “CrUX Methodology” (Stand 20.06.2024) und “Release notes | Chrome UX Report”, alle abgerufen 16.08.2026 – Definition von CrUX; die vier Teilnahmebedingungen für Nutzer und der Ausschluss von Chrome auf iOS, WebView-Apps und anderen Chromium-Browsern; Seitenbedingungen “publicly discoverable” und “sufficiently popular” ohne Nennung einer Besucherzahl; Durchsicht der Release-Notes von Januar 2025 bis zum Juli-2026-Datensatz (veröffentlicht 11.08.2026) ohne neue Core-Web-Vitals-Metrik. Einschränkung: Die Release-Notes wurden zusammenfassend ausgewertet, belastbar für “keine neue Metrik”, nicht für feinere Detailänderungen
- web.dev, Optimierungs- und Vergleichsleitfäden: “Optimize Largest Contentful Paint” (Stand 31.03.2025, Ursachenthemen und Zitat zur Wirkungslosigkeit von Schnelllösungen), “Optimize Cumulative Layout Shift” (Stand 07.02.2025, vier Ursachen im Wortlaut), “Optimize Interaction to Next Paint” (Stand 02.09.2025, Ursachen inklusive großer DOM-Größen), “Why lab and field data can be different” (Stand 18.07.2022, Gründe für abweichende Werte, Priorisierung nach Felddaten) und “Best practices for cookie notices” (Stand 13.06.2024, Zitate zu INP, CLS, LCP und zu Drittanbieter-Bannern), alle abgerufen 16.08.2026
- Chrome for Developers, “Experimenting with measuring soft navigations” (Stand 21.07.2026, abgerufen 16.08.2026) – erklärte Absicht, Soft Navigations in die Core-Web-Vitals-Messung einzubeziehen, zugleich wörtlich “still to be determined” zur Berichterstattung in CrUX. Sowie: The Web Almanac by HTTP Archive, Ausgabe 2025, Kapitel “Performance” (Messmonat Juli 2025, Datenbasis HTTP Archive und CrUX, Millionen von Websites) mit 48 Prozent mobil und 56 Prozent Desktop, und Kapitel “CMS” (veröffentlicht 15.01.2026) mit 45 Prozent für WordPress-Origins und 85 Prozent für Duda-Origins jeweils mobil, beide abgerufen 16.08.2026. Quellentyp Web Almanac: unabhängige Branchenauswertung eines Open-Source-Projekts, kein Google-Dokument; die Werte sind Origin-Anteile und keine Aussage über einzelne Websites
Rote Werte, und niemand sagt dir, was davon wirklich zählt?
Wir lesen deine Felddaten, trennen echten Befund von Laborrauschen und sagen dir ehrlich, welche Maßnahme sich lohnt und welche du dir sparen kannst.
