Warum sich der Blick auf die Core Web Vitals lohnt
Stell dir zwei Ladentüren vor: Die eine öffnet sofort, die andere klemmt drei Sekunden. Beide Läden verkaufen dasselbe — aber vor der klemmenden Tür drehen Kunden wieder ab, bevor sie das Sortiment gesehen haben. Genau diesen Effekt messen die Core Web Vitals für deine Website: nicht, ob dein Inhalt gut ist, sondern ob Besucher ihn schnell, flüssig und ohne Ruckeln erleben.
Google erhebt diese Werte aus den Daten echter Chrome-Nutzer und nutzt sie als Teil des Page-Experience-Signals. Wichtig für die Einordnung: Inhalt und Relevanz wiegen im Ranking deutlich schwerer. Die Core Web Vitals sind selten der Grund, warum eine Seite auf Position 3 statt 1 steht — aber sie sind oft der Grund, warum Besucher abspringen, bevor sie überhaupt lesen, was du anbietest.
Die drei Messwerte im Überblick
| Messwert | Was er misst | Gut | Schlecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Wie schnell der Hauptinhalt sichtbar ist | ≤ 2,5 s | > 4,0 s |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Eingaben reagiert | ≤ 200 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark Inhalte beim Laden verspringen | ≤ 0,1 | > 0,25 |
Google bewertet jeweils den 75. Perzentil-Wert: Mindestens drei Viertel aller gemessenen Seitenaufrufe müssen den Schwellenwert erreichen. Ein schneller Bürorechner mit Glasfaser gleicht also kein langsames Smartphone im Mobilfunknetz aus.
LCP: Wann ist das Wichtigste sichtbar?
Der Largest Contentful Paint misst, wann das größte Inhaltselement im sichtbaren Bereich fertig gerendert ist — meist das Hero-Bild oder die Hauptüberschrift. Er beantwortet die Nutzerfrage: „Sehe ich schon, worum es hier geht?"
Die häufigsten LCP-Bremsen:
- Langsame Serverantwort — bevor der Browser überhaupt anfangen kann, wartet er auf das erste Byte. Hosting-Qualität und Caching sind hier der Hebel.
- Render-blockierendes CSS und JavaScript — Dateien, die der Browser vollständig laden muss, bevor er etwas anzeigt.
- Unoptimierte Hero-Bilder — ein 2-MB-Foto als Titelbild ist der Klassiker. Moderne Formate wie WebP oder AVIF sparen 25–50 % Dateigröße bei gleicher Qualität.
INP: Reagiert die Seite, wenn ich klicke?
Interaction to Next Paint hat im März 2024 den älteren Messwert FID abgelöst. INP misst über den gesamten Seitenbesuch, wie lange die Seite braucht, um auf Klicks, Taps und Tastatureingaben sichtbar zu reagieren.
Ein hoher INP entsteht fast immer durch zu viel JavaScript: Der Browser ist mit Skripten beschäftigt und stellt die Reaktion auf den Klick hinten an. Für die Nutzerin fühlt sich die Seite „eingefroren" an. Typische Ursachen sind schwere Tag-Manager-Setups, Chat-Widgets, A/B-Testing-Tools und Slider-Bibliotheken — jedes Skript einzeln harmlos, in Summe ein Stau.
Die wirksamste Frage ist deshalb nicht „Wie optimiere ich mein JavaScript?", sondern: „Welche dieser Einbindungen brauche ich wirklich?"
CLS: Springt der Inhalt unter dem Finger weg?
Cumulative Layout Shift misst, wie stark sich sichtbare Elemente während des Ladens verschieben. Jeder kennt den Moment: Du willst „Ablehnen" tippen, ein nachladendes Banner schiebt den Knopf nach unten, und du triffst „Akzeptieren". Genau das bestraft CLS.
Die drei häufigsten Ursachen — und ihre einfachen Fixes:
- Bilder ohne feste Größe:
width- undheight-Attribute setzen, damit der Browser den Platz reserviert, bevor das Bild geladen ist. - Nachladende Banner, Einbettungen und Werbung: den benötigten Platz per CSS vorab reservieren.
- Webfonts, die spät laden: Schriften mit
font-display: swapund Preload einbinden, damit der Text nicht umbricht, wenn die Schrift eintrifft.
CLS ist meist der dankbarste der drei Werte: Die Fixes sind klein, gut lokalisierbar und brauchen keine Architektur-Entscheidungen.
So misst du richtig: Feld vor Labor
Es gibt zwei Arten von Messdaten, und ihre Verwechslung ist die häufigste Quelle von Verwirrung:
- Felddaten stammen von echten Chrome-Nutzern deiner Website (aus dem öffentlichen CrUX-Datensatz). Sie sind die Grundlage der Google-Bewertung — aber es gibt sie nur, wenn deine Seite genug Traffic hat.
- Labordaten entstehen in einer simulierten Testumgebung, etwa mit Lighthouse. Sie sind reproduzierbar und ideal zum Debuggen, können aber von der Realität abweichen.
Der praktische Werkzeugkasten:
- PageSpeed Insights — zeigt für jede URL beide Datenarten nebeneinander. Der erste Anlaufpunkt.
- Google Search Console → Core Web Vitals — gruppiert alle Seiten deiner Website nach gut / verbesserungswürdig / schlecht. Ideal, um Muster zu erkennen: Betrifft das Problem eine einzelne Seite oder ein ganzes Template?
- Chrome DevTools (Performance-Panel) — für die Detailanalyse einzelner Interaktionen und Layout-Shifts.
Priorisieren statt alles gleichzeitig
Die Erfahrung aus unseren Audits: Die meisten Websites müssen nicht an allen drei Werten arbeiten. Sinnvolle Reihenfolge:
- Erst Felddaten prüfen. Sind alle drei Werte grün, gibt es Wichtigeres — etwa Inhalte und interne Verlinkung.
- CLS-Probleme zuerst beheben — kleiner Aufwand, sichtbarer Effekt.
- Dann LCP: Hero-Bild optimieren, Caching aktivieren, render-blockierende Ressourcen reduzieren.
- INP zuletzt — meist die aufwendigste Baustelle, weil sie an eingebundenen Drittskripten hängt. Oft ist Entfernen wirksamer als Optimieren.
Ein realistisches Ziel für eine kleine Unternehmens-Website: alle drei Werte im grünen Bereich in den Felddaten. Perfektion in Labor-Scores (die berühmte „100") ist dagegen kein sinnvolles Ziel — sie wird von keiner Suchmaschine belohnt.
Quellen und weiterführende Links
- Core Web Vitals und Google-Suchergebnisse — offizielle Dokumentation von Google Search Central
- web.dev: Core Web Vitals — Definitionen und Schwellenwerte der Messwerte
- PageSpeed Insights — kostenloses Messwerkzeug mit Feld- und Labordaten