Core Web Vitals verstehen: Was Google wirklich misst

01Warum es die Core Web Vitals überhaupt gibt

Drei Zahlen, die versuchen, ein Gefühl messbar zu machen.

Jeder kennt das Gefühl einer Website, die sich zäh anfühlt. Du tippst auf einen Link, es passiert erst mal nichts. Die Seite baut sich auf, du willst einen Button drücken, und im selben Moment rutscht alles nach unten, weil oben noch ein Bild nachgeladen wird. Nichts davon ist ein Fehler im technischen Sinn. Die Seite funktioniert. Sie nervt nur.

Genau dieses Gefühl wollte Google messbar machen. Das Ergebnis heißt Core Web Vitals: drei Kennzahlen für je einen Teil der wahrgenommenen Qualität. Wie lange dauert es, bis der Hauptinhalt sichtbar ist (LCP). Wie schnell reagiert die Seite, wenn ich etwas anfasse (INP). Wie ruhig bleibt das Layout beim Laden (CLS). Zusammen ergeben sie kein vollständiges Qualitätsbild, aber sie treffen gut, worüber sich Besucher tatsächlich ärgern.

Wichtig ist, was die Core Web Vitals nicht sind. Sie sagen nichts über Design, Inhalt, Struktur, Barrierefreiheit oder Rechtssicherheit aus. Eine inhaltsleere Seite kann perfekte Werte haben. Eine hervorragende Seite mit vielen Bildern kann rote Zahlen bekommen und trotzdem gut ranken. Wer sie als Gesamtnote liest, optimiert am Ende Zahlen statt Nutzererlebnis.

Die Definitionen ändern sich außerdem gelegentlich. Bis März 2024 gehörte eine Metrik namens FID zum Kern, sie wurde durch INP ersetzt, weil FID nur die allererste Interaktion gemessen hat und dadurch systematisch zu optimistisch war. Rechne damit, dass sich auch künftig Schwellen verschieben. Verstehe das Prinzip, statt eine Zahl auswendig zu lernen.

02Die drei Metriken im Klartext

Was jede Zahl misst, ab wann sie gut ist und was der Besucher davon merkt.

LCP steht für Largest Contentful Paint. Gemessen wird, wie lange es dauert, bis das größte sichtbare Element im ersten Bildschirmausschnitt fertig dargestellt ist, meist das Hero-Bild oben, manchmal eine große Überschrift. LCP beantwortet die Frage: Wann sieht der Besucher, worum es hier geht? Nicht wann die Seite komplett fertig ist, sondern wann der Hauptinhalt steht.

INP steht für Interaction to Next Paint. Gemessen wird die Verzögerung zwischen einer Interaktion (Klick, Tap, Tastendruck) und dem Moment, in dem der Browser sichtbar reagiert. Und zwar nicht nur beim ersten Mal, sondern über den gesamten Besuch. Aus allen Interaktionen wird der schlechteste realistische Fall genommen. INP beantwortet die Frage: Fühlt sich die Seite reaktionsschnell an, wenn ich sie benutze?

CLS steht für Cumulative Layout Shift. Gemessen wird, wie stark sich sichtbare Elemente während des Ladens verschieben, ohne dass der Nutzer das ausgelöst hat. Der Wert hat keine Einheit, er ist eine Verhältniszahl aus verschobener Fläche und Distanz. CLS beantwortet die Frage: Springt mir die Seite unter dem Finger weg? Diese Metrik hat den direktesten Ärgerfaktor, weil sie zu Fehlklicks führt.

TTFB und FCP gehören nicht zu den Core Web Vitals, tauchen aber in jedem Bericht auf und helfen bei der Fehlersuche. Ein schlechter LCP bei gutem TTFB deutet auf ein Bild- oder Renderproblem hin, ein schlechter LCP bei schlechtem TTFB auf Server oder Hosting. Das ist der Unterschied zwischen "das Bild ist zu groß" und "der Server denkt zu lange nach", und er entscheidet, ob die Lösung zwanzig Minuten oder zwei Tage kostet.

03Feld gegen Labor: warum dein Lighthouse-Wert nicht der Google-Wert ist

Der wichtigste Punkt im ganzen Artikel, und der meistübersehene.

Es gibt zwei Arten von Messdaten, und sie werden ständig verwechselt. Labordaten entstehen, wenn ein Werkzeug wie Lighthouse deine Seite einmal simuliert lädt: gedrosselte Verbindung, simuliertes Mittelklasse-Handy, leerer Cache. Das ist reproduzierbar und gut für die Fehlersuche, aber es bleibt ein Laborexperiment, kein echter Besuch.

Felddaten entstehen aus echten Aufrufen echter Menschen. Google sammelt sie über den Chrome User Experience Report, kurz CrUX, aus Chrome-Nutzern, die der Übermittlung zugestimmt haben. Ausgewertet wird ein rollierendes Fenster der letzten 28 Tage, bewertet wird nicht der Durchschnitt, sondern das 75. Perzentil. Drei Viertel deiner Besucher müssen also den guten Wert erreichen. Ein Durchschnitt wäre zu freundlich, weil schnelle Aufrufe die langsamen kaschieren.

Für die Suche zählt die Feldmessung, nicht dein Lighthouse-Score. Das erklärt die häufigste Verwirrung: Eine Seite kann in Lighthouse 72 Punkte haben und in den Felddaten trotzdem alle drei Core Web Vitals bestehen. Umgekehrt holt eine Seite 98 Punkte im Labor und fällt im echten Leben durch, weil die Zielgruppe mit älteren Android-Geräten im ländlichen Mobilfunknetz unterwegs ist.

Dazu kommt ein praktisches Problem: Für Felddaten braucht es genug Traffic. Hat eine Unterseite zu wenige Aufrufe, zeigt PageSpeed Insights nur Werte für die gesamte Domain oder gar keine. Bei einer kleinen Firmenwebsite ist das der Normalfall. Dann bleibt nur die Labormessung als Näherung, und die liest du entsprechend vorsichtig.

Der Lighthouse-Score selbst ist ein gewichteter Mischwert aus mehreren Labormetriken, unter anderem LCP, CLS, Total Blocking Time und First Contentful Paint. Die Gewichtung ändert sich zwischen Lighthouse-Versionen, deshalb sind Scores aus verschiedenen Jahren nicht direkt vergleichbar. INP kann Lighthouse gar nicht messen, dafür müsste jemand klicken. Stattdessen dient Total Blocking Time als Ersatzsignal, was meist gut korreliert, aber nicht dasselbe ist.

04Typische Ursachen für schlechte Werte

Symptom, Metrik, Ursache, Aufwand: die Fälle, die in der Praxis wirklich vorkommen.

Schlechte Core Web Vitals haben selten exotische Gründe. Meist sind es dieselben sechs bis acht Verursacher, und die wenigsten stammen aus der ursprünglichen Programmierung. Sie kamen nachträglich dazu: ein Tracking-Skript, ein Chat-Widget, ein Slider auf Wunsch der Geschäftsführung.

Die letzte Zeile ist die wichtigste. Performance ist kein Zustand, sondern ein Verlauf. Fast jede Seite, die nach zwei Jahren langsam ist, wurde nicht schlecht gebaut, sondern schrittweise zugeladen. Jedes Skript war für sich harmlos, in Summe sind es zwölf externe Verbindungen, bevor ein Bild erscheint.

Ein Sonderfall verdient eigene Erwähnung: Consent-Banner. Rechtlich meist notwendig, technisch fast immer ein Problem. Viele werden als externes Skript geladen, blockieren das Rendern und binden gleich weitere Dienste ein. Ein sauber gebauter Banner lädt lokal, reserviert seinen Platz und blockiert nichts. Zwischen beiden Varianten liegen schnell ein bis zwei Sekunden LCP.

05Wie du selbst sauber misst

Fünf Werkzeuge, alle kostenlos, jedes mit einem klaren Einsatzzweck.

Du brauchst weder eine Agentur noch ein Abo, um deine Werte zu kennen. Du brauchst die richtige Reihenfolge und das Wissen, welches Werkzeug welche Art von Daten liefert. Wer eine Labormessung mit einer Feldmessung vergleicht und sich über die Abweichung wundert, hat den halben Tag verloren.

Die praktische Reihenfolge: Erstens PageSpeed Insights für die Startseite und die zwei wichtigsten Unterseiten, Mobilansicht zuerst, denn dort entscheidet sich fast alles. Zweitens gilt, wenn Felddaten vorhanden sind, zählen nur diese. Drittens für die Ursachensuche in die DevTools wechseln und mit gedrosselter Verbindung neu laden. Viertens bei INP-Verdacht im Performance-Tab aufzeichnen und dabei wirklich klicken.

• Immer im Inkognito-Fenster messen, sonst verfälschen Browser-Erweiterungen das Ergebnis deutlich.
• Mindestens drei Durchläufe machen und den mittleren Wert nehmen, nicht den besten.
• Mobil und Desktop getrennt betrachten, Google bewertet sie ebenfalls getrennt.
• Nicht nur die Startseite testen. Oft ist eine Leistungsseite oder der Blog das eigentliche Problem.
• Nach jeder Änderung erneut messen, bevor die nächste folgt. Sonst weißt du nie, was gewirkt hat.
• Bei Felddaten Geduld haben: Wegen des 28-Tage-Fensters siehst du Verbesserungen erst Wochen später vollständig.

Diese Werkzeuge sind auch ein Prüfstein für Dienstleister: Miss zwei bis drei Referenzprojekte aus dem Portfolio. Wie du solche Prüfungen systematisch angehst, steht im Ratgeber zum Prüfen von Referenzen. Weist ein Angebot Performance-Optimierung als eigene Position aus, hilft der Ratgeber zum Angebotsvergleich.

06Was die Werte realistisch für dein Ranking bedeuten

Ehrlich eingeordnet, ohne Prozentversprechen.

Google bestätigt, dass Signale zur Seitenerfahrung, zu denen die Core Web Vitals gehören, in die Bewertung einfließen. Google sagt ebenso deutlich, dass Relevanz und Qualität des Inhalts schwerer wiegen. Die zweite Hälfte wird in Verkaufsgesprächen gern weggelassen. Eine schnelle Seite ohne passenden Inhalt rankt nicht vor einer langsameren, die die Frage des Suchenden besser beantwortet.

Die realistische Rolle der Core Web Vitals ist die eines Gleichstands-Entscheiders. Passen zwei Seiten inhaltlich vergleichbar gut zur Suchanfrage, kann die bessere Nutzererfahrung den Ausschlag geben. Bei klarer inhaltlicher Überlegenheit kippt kein LCP-Wert das Ergebnis. Wer dir nennt, um wie viele Plätze du steigst, wenn du grün wirst, rät. Seriöse Zahlen dazu gibt es nicht, dafür wirken zu viele Faktoren gleichzeitig.

Der wirtschaftlich interessantere Effekt läuft ohnehin an Google vorbei. Eine Seite, die schneller nutzbar ist, verliert weniger Besucher vor dem ersten Kontakt. Das wirkt auf jede Quelle gleich: Google, Instagram, Visitenkarte, Empfehlung. Wer nur eine Handvoll relevanter Suchanfragen im Monat hat, sollte Tempo als Konversionsthema behandeln, nicht als SEO-Thema.

Ein dritter Effekt wird selten genannt: Wer für gute Core Web Vitals sorgt, räumt dabei zwangsläufig auf. Weniger Skripte bedeuten weniger Datenabflüsse an Dritte, weniger Einwilligungsbedarf und weniger Angriffsfläche. Lokale Schriften statt Fonts von externen Servern sind gleichzeitig schneller und datenschutzfreundlicher. Performance-Arbeit und DSGVO-Hygiene zeigen oft in dieselbe Richtung.

07Reihenfolge: was zuerst, was später, was nie

Aufwand gegen Wirkung, sortiert nach dem, was sich in der Praxis rechnet.

Wenn du tatsächlich etwas ändern willst, entscheidet die Reihenfolge. Die ersten drei Maßnahmen bringen in fast jedem Projekt den größten Teil der Verbesserung, und keine davon setzt tiefes technisches Wissen voraus. Alles darunter ist Feinschliff, der sich erst lohnt, wenn die Basis sitzt.

Die unterste Zeile steht bewusst dort, weil sie oft zu früh vorgeschlagen wird. Ein Neubau nur wegen Ladezeiten ist selten wirtschaftlich. Trägt die Seite inhaltlich und optisch, holst du mit den ersten fünf Punkten fast immer genug heraus. Steht ohnehin ein Relaunch an, ist Performance ein willkommener Nebeneffekt, aber nicht der Auslöser.

Ein Wort zur Technikwahl beim Neubau: Wer eine Seite als fertige Dateien ausliefert statt sie bei jedem Aufruf neu berechnen zu lassen, startet mit einem kaum einholbaren Vorsprung. Bei Pixylmedia ist Lighthouse 95 plus deshalb kein Optimierungsprojekt am Ende, sondern Folge der Bauweise: keine Plugin-Kette, lokale Schriften, kein US-CDN, Bilder von vornherein richtig dimensioniert.

Umgekehrt gilt: Auch ein sauber gebautes System wird langsam, wenn nach dem Launch ungeprüft Skripte dazukommen. Leg dir eine simple Regel zu: Jedes neue Werkzeug wird vorher und nachher gemessen. Kostet ein Tracking-Tool eine Sekunde LCP, kannst du das bewusst entscheiden. Unbewusst willst du es nicht.

08Fazit: drei Zahlen, richtig eingeordnet

Was du morgen konkret tun kannst, und was du dir sparen darfst.

Die Core Web Vitals sind ein nützliches Werkzeug und ein schlechter Chef. Nützlich, weil sie ein diffuses Gefühl ("die Seite fühlt sich zäh an") in drei überprüfbare Zahlen übersetzen und die Ursachen dahinter benennbar sind. Ein schlechter Chef, weil ein Punktestand zu Aktionismus verleitet. Den Unterschied zwischen 40 und 90 Punkten merkt jeder Besucher. Den zwischen 92 und 100 merkt niemand.

Konkret für die nächste halbe Stunde: Öffne PageSpeed Insights, gib deine Startseite ein und schau dir die Mobilansicht an. Erscheint oben ein Block mit echten Nutzerdaten, zählt nur dieser. Sind alle drei Metriken grün, bist du fertig, schließ den Tab und kümmere dich um Inhalt. Ist etwas rot, notiere die Metrik und geh die Ursachentabelle in diesem Artikel durch. Meistens landest du bei einem zu großen Bild, bei fehlenden Größenangaben oder bei einem Skript, das jemand vor drei Jahren eingebaut und nie wieder angefasst hat.

Ohne Felddaten nimmst du die Labormessung, den Median aus drei Durchläufen, und behandelst das Ergebnis als Richtung, nicht als Urteil. Kommst du gar nicht an den Code, weil du auf einem Baukasten sitzt, lautet die ehrliche Antwort manchmal: Du kannst es nicht lösen, und das darf so sein, solange die Seite ihren Zweck erfüllt.

Zum Schluss die Einordnung, um die es eigentlich geht. Gute Core Web Vitals gewinnen dir keine Kunden. Schlechte kosten dich welche, bevor du die Chance hattest, etwas zu sagen. Schau dir die drei Zahlen einmal im Jahr an und nach jeder größeren Änderung erneut. Danach gehört deine Zeit dem, was auf der Seite steht.