„Meine Website ist doch schnell genug” – diesen Satz höre ich oft, meist von einem nagelneuen Laptop mit Glasfaser-Anschluss aus gesprochen. Das Problem: Ihre Kundschaft sitzt nicht an diesem Laptop. Sie tippt auf einem drei Jahre alten Smartphone im Münchner U-Bahn-Funkloch auf Ihre Seite – und genau diese Erfahrung messen die Core Web Vitals. Sie sind der Versuch, „schnell genug” in drei nachprüfbare Zahlen zu übersetzen.
Kurz gesagt: Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Website objektiv bewertet: LCP (Ladezeit des größten Inhalts, gut: ≤ 2,5 s), INP (Reaktionszeit auf Eingaben, gut: ≤ 200 ms) und CLS (visuelle Stabilität, gut: ≤ 0,1). Gemessen wird an echten Besuchern, am 75. Perzentil – mindestens drei von vier Aufrufen müssen die gute Schwelle erreichen, getrennt für Handy und Desktop. Die Werte fließen als eines von mehreren Signalen ins Google-Ranking ein, vor allem aber entscheiden sie über die Conversion: Jede Sekunde Wartezeit und jeder springende Button kostet Anfragen. Die gute Nachricht für kleine Unternehmen: Die häufigsten Ursachen schlechter Werte – riesige Bilder, zu viele Skripte, fehlende Größenangaben – lassen sich gezielt und ohne großes Budget beheben.
Auf einen Blick
- Drei Werte, drei Fragen: Lädt es schnell (LCP)? Reagiert es flott (INP)? Bleibt das Layout ruhig (CLS)?
- Gute Schwellen: LCP ≤ 2,5 s · INP ≤ 200 ms · CLS ≤ 0,1 – jeweils am 75. Perzentil echter Nutzer.
- Feld schlägt Labor: Entscheidend sind die realen Nutzerdaten (CrUX/Search Console), nicht nur der einmalige Labortest.
- Conversion vor Ranking: Der direkteste Effekt schneller Werte ist nicht Platz 1 bei Google, sondern: Besucher bleiben und fragen an.
Was sind Core Web Vitals?
Core Web Vitals sind drei von Google definierte, messbare Kennzahlen für die Qualität der Nutzererfahrung einer Webseite – Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität. Sie sind der harte, mit echten Nutzerdaten hinterlegte Kern von Googles umfassenderem „Page Experience”-Konzept und seit 2021 ein offizielles Bewertungssignal.
Der Grundgedanke: „Schnell” ist subjektiv, „2,3 Sekunden bis zum größten Inhalt” ist es nicht. Google hat drei Aspekte herausgegriffen, die Besucher unmittelbar als gut oder schlecht erleben, und für jeden einen Messwert mit klaren Schwellen festgelegt. Wichtig ist die Datenquelle: Die offiziellen Core Web Vitals stammen aus dem Chrome User Experience Report (CrUX) – also aus anonymisierten Messungen echter Chrome-Nutzer, nicht aus einem sterilen Labortest. Bewertet wird am 75. Perzentil: Erst wenn mindestens drei von vier Seitenaufrufen die gute Schwelle erreichen, gilt der Wert insgesamt als gut.
Die drei Werte im Detail
LCP – Largest Contentful Paint (Ladegeschwindigkeit)
Largest Contentful Paint (LCP) misst, wie lange es dauert, bis das größte im sichtbaren Bereich dargestellte Element – meist ein Titelbild, eine Überschrift oder ein großer Textblock – vollständig geladen ist. Es ist der Wert, der dem Bauchgefühl „die Seite ist da” am nächsten kommt.
Häufigste Bremsen: unkomprimierte oder überdimensionierte Bilder, langsame Server-Antwortzeiten und render-blockierende Skripte oder Schriften. Der wirksamste Hebel ist fast immer das Bild im sichtbaren Bereich – richtig komprimiert, im modernen Format (WebP/AVIF) und in der passenden Größe ausgeliefert. Wie Sie genau das ohne Programmierkenntnisse umsetzen, zeigt Schritt für Schritt der Beitrag Website-Bilder optimieren: WebP, Komprimierung & Lazy Loading.
INP – Interaction to Next Paint (Reaktionsfähigkeit)
Interaction to Next Paint (INP) misst, wie schnell eine Seite sichtbar auf Eingaben des Nutzers reagiert – also die Zeitspanne von einem Klick, Tippen oder Tastendruck bis zur nächsten Bildschirmaktualisierung, gemessen über alle Interaktionen einer Sitzung. Ein niedriger INP bedeutet: Die Seite fühlt sich „flüssig” an, Buttons reagieren ohne spürbare Verzögerung.
INP hat am 12. März 2024 den älteren Wert FID (First Input Delay) als Core Web Vital abgelöst. Der Unterschied ist mehr als kosmetisch: FID maß nur die Verzögerung der allerersten Interaktion, INP bewertet die Reaktionsfähigkeit über die gesamte Sitzung – und ist damit deutlich strenger. Hauptursache schlechter INP-Werte ist zu viel JavaScript, das den Hauptthread des Browsers blockiert. Genau hier zahlt sich eine schlanke technische Basis aus.
CLS – Cumulative Layout Shift (visuelle Stabilität)
Cumulative Layout Shift (CLS) misst, wie stark sich der sichtbare Seiteninhalt während des Ladens unerwartet verschiebt – etwa wenn ein nachgeladenes Bild oder Werbebanner den Text nach unten drückt, gerade während man auf einen Link tippen will. Es ist der Wert hinter dem alltäglichen Ärgernis, den falschen Button zu treffen.
CLS ist oft der am einfachsten zu behebende Wert: Bilder und eingebettete Elemente bekommen feste Breiten- und Höhenangaben, Schriften werden so geladen, dass sie keinen Umbruch erzwingen, und nachgeladene Inhalte reservieren ihren Platz von Anfang an.
Die Schwellenwerte als Tabelle
| Messwert | Was er misst | Gut | Verbesserungswürdig | Schlecht |
|---|---|---|---|---|
| LCP | Ladezeit des größten Inhalts | ≤ 2,5 s | 2,5–4,0 s | > 4,0 s |
| INP | Reaktionszeit auf Eingaben | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | visuelle Stabilität (Layout-Sprünge) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Alle Schwellen gelten am 75. Perzentil und werden getrennt für Mobil- und Desktop-Geräte ausgewertet. Quelle: web.dev – Core Web Vitals (Google).
Welcher Hebel verbessert welchen Wert?
Statt erfundener Vorher/Nachher-Zahlen hier die ehrliche Zuordnung aus meiner Audit-Praxis: Welche Maßnahme wirkt auf welchen Messwert?
| Maßnahme | Wirkt vor allem auf | Aufwand |
|---|---|---|
| Bilder komprimieren & modernes Format (WebP/AVIF) | LCP | gering |
| Bild im sichtbaren Bereich priorisiert laden | LCP | gering |
| Schriften lokal hosten & vorladen | LCP, CLS | gering |
| Größenangaben (width/height) für Bilder & Embeds | CLS | gering |
| JavaScript reduzieren / aufteilen | INP | mittel |
| Unnötige Plugins & Tracking entfernen | INP, LCP | mittel |
| Schnelleres Hosting / CDN | LCP | mittel |
| Technischer Umstieg auf statische Architektur | alle drei | hoch |
Das Muster ist klar: Die wirksamsten ersten Schritte sind die billigsten. Bilder und Schriften zu zähmen kostet keine Programmierung, bringt aber bei LCP und CLS oft den größten Sprung. Erst wenn die einfachen Hebel ausgereizt sind, lohnt der Blick auf JavaScript und Architektur.
Felddaten vs. Labordaten – ein wichtiger Unterschied
Wer seine Werte prüft, stößt auf zwei Zahlenpaare, die selten übereinstimmen – das verwirrt viele:
- Felddaten (CrUX): echte Messungen echter Besucher der letzten 28 Tage. Das sind die offiziellen Core Web Vitals, die Google fürs Ranking heranzieht. Sie stehen in der Google Search Console und im oberen Teil von PageSpeed Insights.
- Labordaten (Lighthouse): ein einmaliger, simulierter Test unter Standardbedingungen. Praktisch zum Debuggen, weil er sofort Verbesserungsvorschläge liefert – aber kein Ranking-Faktor.
Faustregel: Zum Diagnostizieren Labordaten (Lighthouse) nutzen, zum Bewerten Felddaten (Search Console). Eine neue Seite ohne genug Besucher hat noch gar keine Felddaten – dann ist Lighthouse die einzige Orientierung.
First-Party-Beispiel: die Werte dieser Website
Aus meiner eigenen Praxis als belegbares Beispiel: Diese Website (fabian-reiter.com) ist mit dem Static-Site-Generator Astro gebaut, liefert vorab gerenderte HTML-Seiten aus, hostet ihre Schriften (Hanken Grotesk, Bricolage Grotesque) selbst und verzichtet auf Tracking-Skripte und schwere Plugins. Das Ergebnis ist genau die Architektur, mit der die drei Werte fast von selbst im grünen Bereich landen: Es gibt kaum render-blockierendes JavaScript (gut für INP), die Bilder sind komprimiert und mit Größenangaben versehen (gut für LCP und CLS), und es lädt nichts von fremden Servern nach. Warum diese Bauweise so konsequent schnell ist, beschreibe ich im Beitrag Website in unter 2 Sekunden: Wie Performance mit Astro funktioniert – und den direkten Vergleich der Systeme im Beitrag Astro vs. WordPress 2026.
Wer dagegen auf einer typischen WordPress-Installation mit vielen Plugins schlechte Werte sieht, findet die häufigsten Ursachen und Gegenmittel im Beitrag WordPress-Website langsam? 7 echte Ursachen.
Ehrliche Grenze: gute Werte sind kein Selbstzweck
Perfekte Core Web Vitals machen aus einer schlechten Website keine gute. Sie sind eine notwendige, keine hinreichende Bedingung: Eine blitzschnelle Seite mit unklarem Angebot und ohne sichtbaren Kontaktweg bringt trotzdem keine Anfragen. Google selbst betont, dass relevante, hochwertige Inhalte Vorrang vor der reinen Page Experience haben. Behandeln Sie die Werte deshalb als Hygiene – als das saubere Fundament, auf dem gute Inhalte und eine klare Nutzerführung erst wirken können. Wer die letzten Prozentpunkte einer ohnehin schnellen Seite optimiert, während die Startseite nicht sagt, was das Unternehmen eigentlich anbietet, optimiert am falschen Ende.
Fazit
Core Web Vitals übersetzen das vage „schnell genug” in drei prüfbare Zahlen: Lädt es schnell (LCP ≤ 2,5 s), reagiert es flott (INP ≤ 200 ms), bleibt das Layout ruhig (CLS ≤ 0,1)? Gemessen wird an echten Besuchern, nicht am Entwickler-Laptop. Für kleine Unternehmen ist die wichtigste Erkenntnis: Die häufigsten Ursachen schlechter Werte sind banal – zu große Bilder, zu viele Skripte, fehlende Größenangaben – und gezielt behebbar. Der größte Gewinn ist dabei nicht ein Ranking-Pünktchen, sondern dass weniger Besucher entnervt abspringen.
Nächster Schritt: Sie kennen Ihre Werte nicht – oder PageSpeed Insights zeigt Rot, und Sie wissen nicht, wo Sie anfangen sollen? Bei einem Performance-Fix ab 390 € messe ich Ihre echten Felddaten, ordne die Ursachen nach Wirkung und behebe die größten Bremsen zuerst. Schreiben Sie mir kurz Ihre Domain – ich sage Ihnen ehrlich, welcher Hebel bei Ihnen den größten Unterschied macht.
Quellen
- web.dev – Core Web Vitals (Google) – Definition der drei Messwerte und Schwellenwerte
- web.dev – Interaction to Next Paint (INP) (Google) – INP als Core Web Vital seit 12. März 2024, Ablösung von FID
- web.dev – Largest Contentful Paint (LCP) (Google) – Messung und Optimierung des LCP
- web.dev – Cumulative Layout Shift (CLS) (Google) – Messung und Optimierung der visuellen Stabilität
- Google Search Central – Page Experience (Google) – Rolle der Core Web Vitals im Ranking
- Chrome User Experience Report (CrUX) (Google) – Herkunft der Felddaten
- First-Party-Angabe: technischer Aufbau von fabian-reiter.com (Astro, selbst gehostete Schriften, kein Tracking), Stand Juni 2026