Core Web Vitals sind drei Kennzahlen, mit denen Google das Ladeerlebnis Ihrer Website misst: wie schnell der Hauptinhalt erscheint, wie flüssig die Seite auf Eingaben reagiert und wie stabil das Layout beim Laden bleibt. Für ein KMU zählt davon vor allem, ob Besucher – gerade am Handy – nicht abspringen, bevor die Seite überhaupt nutzbar ist. Den letzten Punkt im Lighthouse-Score zu jagen, wenn die Seite ohnehin schnell lädt, bringt dagegen wenig.
Was LCP, INP und CLS messen
- LCP (Largest Contentful Paint) – wie schnell der grösste sichtbare Inhalt erscheint, etwa das Titelbild oder die Hauptüberschrift. Als gut gilt ein Wert unter 2,5 Sekunden.
- INP (Interaction to Next Paint) – wie zügig die Seite auf Klicks und Eingaben reagiert. Zielbereich: unter 200 Millisekunden.
- CLS (Cumulative Layout Shift) – wie stark Elemente noch verrutschen, während die Seite lädt. Gut ist ein Wert unter 0,1.
Diese Schwellenwerte sind Orientierung, kein Naturgesetz. Sie beschreiben, ab wann ein Besucher die Verzögerung spürt. Massgeblich ist dabei nicht der Durchschnitt: Google bewertet das 75. Perzentil der realen Seitenaufrufe – drei von vier Besuchern müssen den Wert also erreichen, nicht der Mittelwert.
Welche vier Treiber die Ladezeit tatsächlich bestimmen
Die meisten spürbaren Verbesserungen kommen aus wenigen Treibern – in dieser Reihenfolge lohnt sich der Blick:
- Bilder: zu grosse Dateien sind die häufigste Bremse. Richtige Abmessungen und moderne Formate bringen oft den grössten Sprung.
- Server-Antwortzeit: reagiert das Hosting träge, hilft kein Frontend-Trick. Hier zählt die Grundausstattung.
- Render-blockierende Skripte: Code, der das Anzeigen verzögert, lässt sich oft später laden oder entfernen.
- Reservierter Platz für Bilder, Banner und eingebettete Inhalte verhindert die Layout-Sprünge, die zu CLS führen.
Warum Labormessung und Felddaten verschiedene Dinge sagen
Der häufigste Irrtum bei diesem Thema: Man hält den Lighthouse-Score für die Core Web Vitals. Es sind zwei verschiedene Messungen mit zwei verschiedenen Zwecken.
| Labormessung (Lighthouse, PageSpeed) | Felddaten (Chrome UX Report, Search Console) | |
|---|---|---|
| Woher kommen die Werte? | eine simulierte Messung auf Knopfdruck | echte Besuche echter Chrome-Nutzer |
| Wofür zählt Google sie? | gar nicht | das ist die Bewertung |
| Enthält sie INP? | nein – INP braucht eine echte Interaktion | ja |
| Sofort verfügbar? | ja, jederzeit reproduzierbar | nein, gleitendes Fenster über die letzten Wochen |
| Auch bei wenig Traffic? | ja | oft nicht – ohne genügend Besuche gibt es keine Felddaten |
| Wozu taugt sie? | Ursachen finden, Änderungen vergleichen | den tatsächlichen Zustand beurteilen |
Für viele kleinere KMU-Websites ist genau der vorletzte Punkt der entscheidende: Bei zu wenig Traffic liefert Google gar keine Felddaten. Dann existiert keine Bewertung, die man verbessern könnte – und die Labormessung ist alles, was man hat. Wer in dieser Lage einen Score jagt, optimiert eine Zahl, die niemand sonst sieht.
Wie Sie Ihre Core Web Vitals selbst messen
- Zuerst nach Felddaten schauen. Search Console → Bericht «Core Web Vitals», oder PageSpeed Insights: Der obere Block zeigt Felddaten, der untere die Labormessung. Sind keine Felddaten vorhanden, ist das eine Antwort für sich (siehe oben) – dann arbeiten Sie mit dem Labor-Teil weiter.
- Mobil messen, nicht Desktop. Die Bewertung erfolgt getrennt, und der Engpass liegt fast immer beim Handy. Ein Desktop-Ergebnis auf schnellem Büro-Netz sagt über Ihre Besucher wenig aus.
- Nach Seitentyp gruppieren, nicht Einzelseiten jagen. Startseite, Leistungsseite, Blogartikel verhalten sich unterschiedlich, aber innerhalb eines Typs meist gleich. Eine Seite pro Typ zu prüfen genügt.
- Für die Ursache in die Labormessung. Sie benennt das konkrete LCP-Element und die blockierenden Skripte. Das ist der Punkt, an dem die Labormessung ihren Wert hat – nicht bei der Beurteilung.
- Nach einer Änderung neu messen, aber die richtige Quelle. Die Labormessung zeigt den Effekt sofort, die Felddaten erst nach Wochen. Wer den Erfolg an den Felddaten misst, wartet – wer ihn an der Labormessung misst, sieht ihn früh, aber nicht das, was Google bewertet.
Zwei Fallstricke, die die Beurteilung kippen:
- Der Lighthouse-Score ist nicht die Core Web Vitals. Er ist eine gewichtete Labor-Kennzahl und enthält INP gar nicht, weil eine simulierte Messung niemanden klicken lässt. Ein Score von 100 und schlechte Felddaten schliessen sich nicht aus.
- Der Cache verdeckt das Problem. Wer die eigene Seite zum zehnten Mal aufruft, misst einen aufgewärmten Browser und ein aufgewärmtes Hosting. Der Erstbesucher – also der, um den es geht – erlebt etwas anderes. Im privaten Fenster messen.
Wo Score-Optimierung nichts mehr bringt
Wenn Ihre Seite bereits schnell und stabil lädt, bringt das letzte Hundertstel im Score keinen echten Besucher zurück. Score-Optimierung um jeden Preis bindet Budget, das in Inhalt, Struktur oder Erreichbarkeit besser aufgehoben wäre.
Geschwindigkeit ist Hygiene, kein Selbstzweck: Ein paar gezielte Eingriffe wirken stärker als das Jagen nach einer perfekten Zahl.
Wie Ladezeit auf Anfragen und Sichtbarkeit wirkt
Eine langsame Seite ist ein häufiger Grund, warum Besucher abbrechen, bevor sie zur Anfrage oder zum Kauf kommen – besonders auf dem Mobiltelefon und bei schwachem Empfang. Tempo wirkt damit indirekt auf Ihre Conversion und, weil Google die Werte berücksichtigt, auch auf die Sichtbarkeit in der Suche.
Was Tempo nicht leistet: Es ersetzt keinen Inhalt. Eine schnelle Seite, die die Frage des Besuchers nicht beantwortet, verliert ihn genauso – nur zügiger.
Ihre Besucher entscheiden, bevor die Seite fertig geladen ist
Wer auf dem Handy in der Bahn Ihre Website öffnet und drei Sekunden auf ein weisses Feld schaut, geht zurück zur Trefferliste. Er hat nicht entschieden, dass Ihr Angebot schlecht ist – er hat gar nichts von Ihrem Angebot gesehen.
Genau das misst Google mit den Core Web Vitals: nicht, wie hübsch Ihre Seite ist, sondern wie sie sich in den ersten Sekunden anfühlt. Erscheint der Inhalt zügig? Reagiert die Seite auf einen Klick? Oder verrutscht der Text noch, während man ihn zu lesen beginnt – und man tippt versehentlich auf ein Werbebanner?
Der zweite Teil ist der wichtigere und wird oft überhört: Es geht nicht darum, eine perfekte Zahl zu erreichen. Es geht darum, dass niemand vorher geht.
Was hinter den drei Abkürzungen steckt
Google fasst das Ladeerlebnis in drei Werten zusammen, und alle drei tragen englische Kürzel, die niemandem etwas sagen. Aufgelöst sind sie erstaunlich anschaulich.
LCP – wann der Inhalt erscheint
LCP steht für «Largest Contentful Paint», also sinngemäss: wann der grösste sichtbare Inhalt fertig gezeichnet ist – meist das Titelbild oder die Hauptüberschrift. Vorher sieht der Besucher wenig bis nichts. Alles unter rund zweieinhalb Sekunden gilt als gut.
INP – ob die Seite reagiert
INP steht für «Interaction to Next Paint», also die Spanne zwischen einem Klick und dem Moment, in dem sichtbar etwas passiert. Reagiert eine Seite nicht sofort, klicken Menschen ein zweites Mal – und ärgern sich, wenn dann beides ausgelöst wird.
CLS – ob das Layout stillhält
CLS steht für «Cumulative Layout Shift», auf Deutsch etwa «aufsummiertes Verrutschen des Layouts». Es misst, wie stark Texte und Bilder noch verspringen, während die Seite lädt. Nachgeladene Bilder ohne reservierten Platz schieben den Text nach unten. Das ist der Grund, warum man beim Lesen plötzlich woanders landet, als man tippen wollte.
Warum ich Tempo als Hygiene behandle und nicht als Projekt
Ladezeit ist der einzige Bereich der Webanalyse, in dem ich regelmässig erlebe, dass zu viel investiert wird statt zu wenig. Ein Score wird zur Trophäe, es wird an Millisekunden gefeilt – und die Seite beantwortet die Frage des Kunden immer noch nicht.
Technisch ist die Lage meist unspektakulär. In den allermeisten Fällen liegt die Bremse bei zu grossen Bildern oder einem trägen Hosting. Das sind zwei Eingriffe, keine Kampagne. Was danach kommt, ist Feinschliff mit sinkendem Ertrag.
Wirtschaftlich ist die Rechnung deshalb schnell gemacht: Die ersten Eingriffe kosten wenig und bringen viel. Wer darüber hinaus optimiert, verschiebt Budget von einer Frage, die Kunden interessiert, hin zu einer Zahl, die nur ein Werkzeug ausgibt. Meine Reihenfolge ist immer dieselbe – erst die zwei groben Bremsen lösen, dann aufhören und das Geld in den Inhalt stecken.
Was ich Ihnen nicht verspreche: dass eine schnelle Seite Ihnen Aufträge bringt. Sie sorgt nur dafür, dass die Seite gelesen wird. Ob sie überzeugt, entscheidet, was daraufsteht.
Häufige Fragen
Brauche ich für gute Core Web Vitals ein teures Hosting?
Nicht zwingend. Oft liegt die Bremse bei Bildern oder Skripten, nicht am Server. Erst wenn die Antwortzeit messbar träge ist, lohnt sich der Blick auf die Hosting-Grundausstattung.
Muss ich einen Lighthouse-Score von 100 erreichen?
Nein – und der Score ist ohnehin nicht das, was Google bewertet. Massgeblich sind die Felddaten echter Besucher. Ein hoher Score bei schlechten Felddaten ist möglich und kommt vor. Entscheidend ist, ob reale Besucher die Seite als schnell und stabil erleben.
Wie messe ich die Werte überhaupt?
Über Felddaten aus der Search Console oder PageSpeed Insights – das ist die Bewertung – und über eine Labormessung, wenn Sie die Ursache suchen. Hat Ihre Website zu wenig Besucher, liefert Google gar keine Felddaten; dann bleibt nur die Labormessung, und eine offizielle Bewertung existiert schlicht nicht.
