Core Web Vitals Test — Ladezeit und PageSpeed messen

Was die Core Web Vitals sind — und warum ausgerechnet diese drei

Ladezeit war jahrelang eine Zahl, über die sich niemand einig wurde. Der eine maß, wann der Server antwortet, der nächste, wann das Ladesymbol im Browser-Tab aufhört zu drehen, der dritte, wann das letzte Tracking-Pixel durch ist. Keiner dieser Werte beschrieb, was ein Mensch vor dem Bildschirm tatsächlich erlebt.

Genau dort setzen die Core Web Vitals an. Google hat drei Fragen ausgewählt, die aus Sicht eines Besuchers zählen: Sehe ich schon etwas? Bleibt es da, wo es ist? Reagiert es, wenn ich es antippe? Daraus wurden drei Messwerte — LCP, CLS und INP. Sie sind bewusst so gewählt, dass sie sich mit echten Nutzern im Feld messen lassen und nicht nur im Labor.

Seit 2021 sind sie Teil der Bewertungssignale in der Google-Suche. Seit März 2024 hat INP den älteren Wert FID abgelöst. Die Schwellenwerte sind seither unverändert geblieben, und das ist kein Zufall: Google hat sie so festgelegt, dass sie für gut gebaute Seiten erreichbar sind, ohne dabei belanglos zu werden.

Ein wichtiges Detail, das gern übersehen wird: Bewertet wird nicht der Durchschnitt, sondern das 75. Perzentil deiner Besucher. Eine Seite gilt erst dann als gut, wenn drei von vier Ladevorgängen unter der Schwelle liegen. Das ist absichtlich streng — der Durchschnitt würde die langsame Hälfte deiner Nutzer unsichtbar machen, und genau die springen ab.

LCP — wann der Hauptinhalt endlich da ist

Largest Contentful Paint misst, wann das größte sichtbare Element im ersten Bildschirm fertig gezeichnet ist. In der Praxis ist das fast immer das Titelbild, ein Produktfoto oder bei textlastigen Seiten der große Überschriftenblock. Der Gedanke dahinter ist bestechend einfach: Wenn das größte Element steht, empfindet ein Mensch die Seite als geladen — auch wenn im Hintergrund noch dreißig Anfragen laufen.

LCP setzt sich aus vier Abschnitten zusammen, und es lohnt sich zu wissen, welcher davon deine Zeit frisst:

• Serverantwort (TTFB): Wie lange dauert es, bis überhaupt das erste Byte kommt?
• Ladeverzögerung: Wie viel Zeit vergeht zwischen dem ersten Byte und dem Moment, in dem der Browser das LCP-Element überhaupt anfordert?
• Ladedauer: Wie lange braucht die Übertragung des Bildes selbst?
• Renderverzögerung: Wie viel Zeit liegt zwischen dem fertigen Download und dem Erscheinen auf dem Bildschirm?

Die häufigsten Ursachen für schlechtes LCP

Riesige, unoptimierte Bilder. Das ist mit Abstand der häufigste Fall. Ein Titelbild, das mit 3.000 Pixel Breite und 2 MB aus der Kamera kommt und per CSS auf 800 Pixel geschrumpft wird, ist eine reine Zeitverschwendung — auf einem Mobilnetz kostet es Sekunden. Wer solche Bilder auf eine sinnvolle Größe bringt und in WebP oder AVIF ausliefert, spart typischerweise 60 bis 80 Prozent. Genau dafür haben wir den Bild-Komprimierer gebaut: Er läuft komplett im Browser, konvertiert nach WebP und AVIF und zeigt dir vorher und nachher im Vergleich.

Lazy Loading am falschen Ort. loading="lazy" ist ein Segen — für alles unterhalb der Falte. Auf dem Titelbild ist es ein Eigentor: Der Browser wartet erst, bis er weiß, dass das Bild sichtbar wird, und lädt dann. Das Bild, das dein LCP bestimmt, gehört ohne lazy loading ins HTML, gern mit fetchpriority="high".

Bilder, die aus JavaScript kommen. Wenn ein Slider oder ein Bildergalerie-Skript das Titelbild erst nachträglich einfügt, kann der Vorlader des Browsers es beim Durchsehen des HTML nicht finden. Die Folge ist eine lange Ladeverzögerung, obwohl das Bild selbst klein ist.

Langsame Serverantwort. Über 800 Millisekunden TTFB ist ein Warnsignal. Ursache sind meist ungecachte Datenbankabfragen, ein überbuchtes Shared Hosting oder ein Server auf einem anderen Kontinent als die Besucher. Ein Vollseiten-Cache oder ein CDN ändert hier oft mehr als jede Frontend-Optimierung.

Rendering-blockierende Dateien. Jedes Stylesheet und jedes Skript im Kopfbereich hält den Seitenaufbau an. Kritisches CSS gehört inline, der Rest wird nachgeladen, und Skripte bekommen defer.

CLS — wenn die Seite unter dem Finger wegspringt

Cumulative Layout Shift ist der Wert, den jeder sofort versteht, sobald man ihn erlebt hat: Du willst auf einen Link tippen, im selben Moment lädt darüber ein Banner nach, alles rutscht nach unten — und dein Finger landet auf einer Werbeanzeige. CLS beziffert genau das. Er ist kein Zeitwert, sondern ein dimensionsloses Maß aus der Fläche des verschobenen Inhalts und der Distanz, um die er sich bewegt hat.

Zwei Dinge sind wichtig zu wissen. Erstens: Nur unerwartete Verschiebungen zählen. Ein Menü, das sich nach deinem Klick ausklappt, ist kein Layoutsprung — Verschiebungen innerhalb von 500 Millisekunden nach einer Nutzereingabe werden nicht gewertet. Zweitens: Gezählt wird über die gesamte Lebensdauer der Seite, in Fenstern von je fünf Sekunden. Ein Banner, das erst nach dreißig Sekunden Scrollen erscheint und alles verschiebt, geht genauso ein wie einer beim Laden.

Die häufigsten Ursachen für schlechtes CLS

• Bilder ohne width und height. Ohne Größenangaben weiß der Browser nicht, wie viel Platz zu reservieren ist. Er rendert den Text, das Bild kommt an, alles rutscht. Die Lösung ist ein Zweizeiler: width und height als Attribute setzen, das moderne CSS rechnet daraus das Seitenverhältnis und hält den Platz frei.
• Werbung und Einbettungen ohne festen Platz. Anzeigen, Kartendienste, Video-Player, Cookie-Banner und Newsletter-Popups schieben sich in fertigen Text hinein. Reserviere die Fläche im Voraus mit einem Container fester Höhe — auch wenn sie mal leer bleibt.
• Schriften, die beim Tausch die Breite ändern. Wenn zuerst eine Systemschrift angezeigt und dann die Hausschrift eingetauscht wird, ändert sich die Textbreite und der Umbruch. Abhilfe: die wichtigste Schrift per preload laden und eine Ersatzschrift mit ähnlichen Maßen definieren.
• Inhalte, die oben eingefügt werden. Ein Hinweisbalken, der nachträglich über allem erscheint, verschiebt die komplette Seite. Entweder von Anfang an mitrendern oder als Overlay über den Inhalt legen.

CLS ist erfahrungsgemäß die Metrik mit dem besten Verhältnis von Aufwand zu Wirkung. Die meisten Seiten kommen mit ein paar Attributen und einer reservierten Fläche von 0,3 auf unter 0,05 — das ist Arbeit für einen Nachmittag, nicht für ein Quartal.

INP — der Wert, der FID abgelöst hat

Interaction to Next Paint misst, wie lange es dauert, bis die Seite auf eine Eingabe sichtbar reagiert. Gemessen wird vom Klick, Tipp oder Tastendruck bis zu dem Moment, in dem der Browser das nächste Bild zeichnet. Betrachtet werden alle Interaktionen einer Sitzung; als INP-Wert der Seite gilt praktisch die schlechteste davon (bei sehr vielen Interaktionen wird das oberste Ausreißerfeld ausgeklammert).

Im März 2024 hat INP den Vorgänger FID ersetzt, und das war überfällig. FID maß nur die Verzögerung der ersten Eingabe, und auch nur bis zum Beginn der Verarbeitung. Was danach passierte — die eigentliche Arbeit, das Neuzeichnen — blieb außen vor. Das Ergebnis war ein Wert, den über 90 Prozent aller Seiten bestanden, auch solche, die sich in Wahrheit zäh anfühlten. INP schaut auf die ganze Kette und ist damit deutlich ehrlicher. Entsprechend fallen mehr Seiten durch.

Warum unser Test dir keinen INP-Wert zeigt

Das ist der Punkt, an dem viele Konkurrenz-Tools schummeln, und deshalb sagen wir es deutlich: INP lässt sich im Labor nicht messen. Der Wert entsteht erst, wenn ein Mensch klickt. Ein automatisierter Ladevorgang klickt nicht, also gibt es keine Interaktion, also gibt es keinen INP. Lighthouse weist deshalb keinen Laborwert aus — und wir erfinden keinen.

Was wir stattdessen zeigen, ist die Total Blocking Time. TBT summiert alle Zeitanteile, in denen der Hauptthread länger als 50 Millisekunden am Stück mit einer Aufgabe beschäftigt war. Genau in diesen Fenstern könnte die Seite auf einen Klick nicht reagieren. TBT ist damit der beste im Labor verfügbare Frühindikator für INP: Ein hoher Wert bedeutet fast sicher schlechtes INP im Feld. Umgekehrt gilt es aber nicht — eine Seite mit sauberem TBT kann trotzdem schlechtes INP haben, wenn ausgerechnet der Klick-Handler teuer ist.

Die häufigsten Ursachen für schlechtes INP

• Zu viel JavaScript. Jedes Kilobyte muss übertragen, ausgewertet und ausgeführt werden. Währenddessen ist der Hauptthread blockiert.
• Lange Aufgaben ohne Unterbrechung. Ein Skript, das 400 Millisekunden am Stück rechnet, blockiert jede Eingabe in dieser Zeit. Große Aufgaben lassen sich aufteilen, sodass der Browser dazwischen Eingaben verarbeiten kann.
• Teure Event-Handler. Wenn beim Klick erst Daten geholt, dann das halbe DOM neu aufgebaut wird, dauert die Reaktion. Zeig sofort eine sichtbare Rückmeldung und erledige die schwere Arbeit danach.
• Fremdskripte. Tracking, Chat-Widgets, Werbung, Consent-Manager — sie belegen den Hauptthread mit Arbeit, von der dein Nutzer nichts hat.
• Riesiges DOM. Zehntausende Elemente machen jede Layoutberechnung teuer, und die fällt bei jeder Interaktion an.

Labordaten und Felddaten: warum sich beide widersprechen dürfen

Das ist die wichtigste Unterscheidung dieser ganzen Seite, und sie erklärt fast jede Verwirrung rund um Core Web Vitals.

Labordaten — das, was dieser Test liefert — entstehen aus einem einzelnen, kontrollierten Ladevorgang. Ein Rechenzentrumsserver lädt deine Seite in einem echten Chrome, simuliert dabei ein Mittelklasse-Smartphone und drosselt die Verbindung. Der große Vorteil: Das Ergebnis ist reproduzierbar, sofort verfügbar und zeigt dir die Ursachen. Du kannst eine Änderung machen und zwei Minuten später sehen, ob sie gewirkt hat. Der Nachteil: Es ist eine Simulation. Ein Server im Rechenzentrum ist nicht dein Besucher im Zug.

Felddaten stammen aus dem Chrome User Experience Report (CrUX): echte Messungen von echten Chrome-Nutzern, die der Datenweitergabe zugestimmt haben, aggregiert über die letzten 28 Tage. Genau diese Daten nutzt Google für die Bewertung, und genau sie siehst du in der Search Console. Der Vorteil: Es ist die Wahrheit. Die Nachteile: Sie brauchen genug Verkehr, um überhaupt zu existieren, sie reagieren erst nach Wochen auf Änderungen, und sie sagen dir nicht, warum etwas langsam ist.

Typische Fälle, in denen beide auseinanderlaufen:

• Labor gut, Feld schlecht: Deine Besucher sitzen auf älteren Geräten oder in schlechteren Netzen als die Simulation annimmt. Oder ein Cookie-Banner blockiert bei echten Nutzern das Rendern, während der Testlauf ihn nie zu Gesicht bekommt.
• Labor schlecht, Feld gut: Wiederkehrende Besucher haben deine Dateien im Cache. Der Testlauf startet immer mit leerem Cache — dem härtesten Fall.
• INP nur im Feld schlecht: Der Klassiker. Im Labor gibt es keine Interaktion, also fällt die zähe Suchfunktion erst auf, wenn echte Menschen sie benutzen.

Die vernünftige Arbeitsweise nutzt beides: Felddaten aus der Search Console sagen dir, ob und wo du ein Problem hast. Ein Labortest wie dieser sagt dir, warum — und lässt dich in Minuten statt Wochen prüfen, ob deine Reparatur wirkt.

Der Performance-Score: nützlich, aber kein Zeugnis

Die große Zahl im Farbring ist der Lighthouse-Performance-Score. Er fasst fünf Labormetriken gewichtet zusammen — Total Blocking Time und Largest Contentful Paint machen zusammen den größten Teil aus, dazu kommen Speed Index, First Contentful Paint und Cumulative Layout Shift. Ab 90 ist er grün, unter 50 rot.

Drei ehrliche Einordnungen dazu. Erstens: Der Score ist nicht der Wert, der ins Ranking einfließt. Google bewertet die Core Web Vitals aus Felddaten, nicht diesen Laborscore. Zweitens: Er schwankt. Fünf bis zehn Punkte Unterschied zwischen zwei Läufen derselben Seite sind normal, weil Netzwerk und Serverlast schwanken. Wer jeden Punkt jagt, misst Rauschen. Drittens: 100 zu erreichen ist kein Ziel an sich. Der Sprung von 45 auf 80 verändert das Erlebnis deiner Besucher spürbar. Der von 92 auf 98 kostet meist Tage und merkt niemand.

Wie viel bringen Core Web Vitals fürs Ranking wirklich?

Hier wird viel übertrieben, in beide Richtungen. Die nüchterne Antwort:

Die Seitenerfahrung ist ein Zusatzsignal, kein Hauptfaktor. Google hat das mehrfach und deutlich gesagt: Eine Seite mit den besten Werten der Welt rankt nicht für ein Thema, das sie nicht behandelt. Relevanz und Inhaltsqualität entscheiden zuerst. Bei zwei Seiten mit ähnlich gutem Inhalt kann die Geschwindigkeit den Ausschlag geben — deshalb ist „Tiebreaker“ die passendste Beschreibung.

Der indirekte Effekt ist der größere, und über den redet kaum jemand. Schnellere Seiten haben messbar niedrigere Absprungraten, mehr gesehene Seiten pro Besuch und höhere Abschlussquoten. Diese Zusammenhänge sind über Branchen hinweg gut belegt. Sie wirken auf deinen Umsatz, völlig unabhängig davon, ob Google einen Rankingpunkt vergibt.

Und eine Sache ist eindeutig: Eine Seite, die im Feld rot ist — LCP über vier Sekunden, CLS über 0,25 — hat ein echtes Problem, das man reparieren sollte. Nicht wegen Google, sondern weil Menschen abspringen. Der Weg von rot nach grün lohnt sich immer. Der Weg von grün nach etwas grüner selten.

Eine sinnvolle Reihenfolge zum Abarbeiten

1. Bilder zuerst. Größe, Format, Kompression. Das ist die häufigste LCP-Ursache und die schnellste Verbesserung. Der Bild-Komprimierer erledigt das in einem Rutsch.
2. Das LCP-Element bevorzugt behandeln. Kein lazy loading auf dem Titelbild, fetchpriority="high" setzen, Vorverbindungen zu fremden Bilddiensten aufbauen.
3. Platz reservieren. width und height an alle Bilder, feste Höhen für Werbeflächen und Einbettungen. CLS ist damit meist erledigt.
4. Serverantwort prüfen. Über 800 ms TTFB? Caching und CDN bringen hier mehr als jede weitere Frontend-Arbeit.
5. JavaScript ausmisten. Was wird wirklich gebraucht? Fremdskripte sind die üblichen Verdächtigen und meistens verzichtbarer, als alle denken.
6. Rendering entblocken. Kritisches CSS inline, den Rest asynchron, Skripte mit defer.
7. Danach im Feld nachschauen. Zwei bis vier Wochen später zeigt die Search Console, ob es bei echten Nutzern angekommen ist.

Wie dieser Test arbeitet

Wenn du auf „Test starten“ klickst, geht deine Adresse an unseren Server. Dort läuft Google Lighthouse in einem echten Chromium — dieselbe Software, die auch hinter PageSpeed Insights und den Entwicklertools deines Browsers steckt. Die Seite wird vollständig geladen, mit simuliertem Mittelklasse-Smartphone und gedrosselter Verbindung, und dabei vermessen. Das dauert typischerweise 30 bis 60 Sekunden. Wir zeigen dir währenddessen die tatsächliche Phase und die echte Laufzeit, keinen erfundenen Fortschrittsbalken.

Das ist bewusst eine Ausnahme in unserem Werkzeugkasten. Der Bild-Komprimierer, der QR-Code-Generator und der Meta-Title-Generator laufen zu 100 Prozent in deinem Browser, ohne dass irgendetwas hochgeladen wird. Hier geht das technisch nicht: Ein Browser darf aus Sicherheitsgründen die Ladezeiten einer fremden Domain nicht auslesen. Also muss die Messung serverseitig laufen — und wir sagen das lieber deutlich, als es zu verschweigen. Die eingegebene Adresse bleibt höchstens 15 Minuten im Arbeitsspeicher, damit du das Ergebnis abrufen kannst, und wird danach verworfen. Keine Datenbank, kein Verlauf, kein Konto.

Häufige Fragen

Gemessen wird mit Google Lighthouse in einem headless Chromium auf unserem Server, mit den Standardeinstellungen für simuliertes Mobilgerät beziehungsweise Desktop. Die Ergebnisse sind Labordaten eines einzelnen Ladevorgangs und können von den Felddaten in der Google Search Console abweichen. Die genannten Schwellenwerte entsprechen Googles offizieller Definition der Core Web Vitals (Stand 2026).