Core Web Vitals werden häufig als SEO-Thema behandelt und sind vor allem ein Umsatzthema. Das Ranking-Gewicht ist real, aber gering; der Effekt auf abgeschlossene Formulare und Käufe ist deutlich größer.
Die drei Kennzahlen
| Kennzahl | Misst | Gut | Schlecht |
|---|---|---|---|
| LCP | Wann erscheint der größte sichtbare Inhalt? | < 2,5 s | > 4 s |
| INP | Wie schnell reagiert die Seite auf Eingaben? | < 200 ms | > 500 ms |
| CLS | Wie stark verschiebt sich das Layout? | < 0,1 | > 0,25 |
Bewertet wird das 75. Perzentil echter Nutzer über 28 Tage. Das heißt: Drei von vier Besuchen müssen den Wert erreichen. Ihr eigener Besuch auf einem schnellen Rechner mit warmem Cache gehört fast nie zu dem Viertel, das das Problem hat.
Zuerst: die richtigen Daten ansehen
- Felddaten — Search Console, Chrome UX Report. Das sind die Werte, die zählen.
- Labordaten — Lighthouse, WebPageTest. Nützlich zur Fehlersuche, irrelevant für die Bewertung.
Der verbreitetste Irrtum ist, Lighthouse zu optimieren. Ein Wert von 95 im Labor bei durchgefallenen Felddaten bedeutet: Sie haben unter Bedingungen gemessen, unter denen Ihre Nutzer nicht surfen.
LCP: fast immer dieselbe Ursache
In der überwiegenden Zahl der Fälle ist das LCP-Element ein Bild — und das Problem ist, wie es geladen wird.
Der häufigste Fehler: Das erste sichtbare Bild wird mit loading="lazy"
oder über eine Lazy-Loading-Bibliothek geladen. Die Ladekette wird dadurch
länger: HTML lesen → Skript laden → Skript ausführen → Element finden →
Quelle setzen → erst jetzt Bild laden. Der Preload-Scanner des Browsers, der
das Bild sonst sofort angefordert hätte, ist ausgehebelt.
Die Regel: Das erste sichtbare Bild bekommt ein normales src und
fetchpriority="high". Lazy Loading gilt ausschließlich für alles unterhalb
der Falte.
Die weiteren LCP-Ursachen in absteigender Häufigkeit:
- Nicht optimierte Bilder — 800 KB PNG, wo 60 KB WebP genügen
- Blockierende Schriften — Text unsichtbar, bis die Schrift geladen ist;
font-display: swapbehebt das - Langsame Serverantwort — wenn die erste Antwort über 600 ms braucht, ist alles Weitere Symptombehandlung
- Render-blockierendes CSS und JavaScript im Kopf des Dokuments
INP: strenger als sein Vorgänger
INP misst jede Interaktion über den gesamten Besuch. Der Vorgänger FID maß nur die erste — und war dadurch leicht zu bestehen, während sich die Seite träge anfühlte.
Typische Ursachen:
- Zu viel JavaScript beim Start. Jedes Skript im Hauptthread verzögert die Reaktion auf Eingaben.
- Aufwendige Arbeit im Klick-Handler. Filtern, Sortieren, Rechnen über große Listen direkt im Ereignis.
- Layout-Neuberechnung durch Lesen und Schreiben im Wechsel.
- Marketing-Skripte von Drittanbietern. Häufig der größte Einzelposten und der am wenigsten kontrollierte.
Der wirksamste Hebel ist fast immer, weniger JavaScript auszuliefern statt es zu optimieren.
CLS: die leichteste Kennzahl
CLS ist mit vier Maßnahmen praktisch immer lösbar:
- Breite und Höhe an allen Bildern und Videos — der Browser reserviert den Platz vorab
- Platz für Werbung und Einbettungen reservieren, auch wenn sie später geladen werden
- Keine Inhalte oberhalb bestehender einfügen — Banner gehören ans Ende oder in eine feste Position
- Schriften mit passenden Ersatzmaßen laden, damit der Umbruch beim Wechsel nicht springt
Wenn CLS schlecht ist, fehlt in der Regel schlicht Punkt 1.
Was messbar wirkt — nach Aufwand und Nutzen
| Maßnahme | Aufwand | Wirkung |
|---|---|---|
| Lazy Loading vom LCP-Bild entfernen | Minuten | sehr hoch |
| Bilder als WebP/AVIF, korrekt dimensioniert | Stunden | hoch |
| Größe und Seitenverhältnis an allen Bildern | Stunden | hoch (CLS) |
| Drittanbieter-Skripte prüfen und entfernen | Tage | hoch (INP) |
font-display: swap | Minuten | mittel |
| CDN und Caching | Tage | mittel |
| Framework-Umbau | Wochen | oft gering |
Die letzte Zeile ist die wichtigste: Ein Framework-Wechsel wird häufig als Performance-Maßnahme verkauft und ist selten die Ursache. Arbeiten Sie zuerst die oberen fünf Zeilen ab — in den meisten Projekten ist das Thema danach erledigt.
Ein Detail, das regelmäßig in die Irre führt
Eine Datei, die im Projekt liegt, aber nirgends referenziert wird, ist kein Performance-Problem — sie wird nie geladen. Wir sehen regelmäßig Aufräumaktionen, die Megabytes ungenutzter Bilder entfernen und an den Messwerten nichts ändern.
Ebenso irreführend: eine Datei, die noch nicht deployed ist, vom Produktionssystem aus zu messen. Wenn die Seite keinen echten 404 liefert, bekommen Sie stattdessen das HTML der Startseite zurück — und halten ein Bild für riesig, das gar nicht existiert. Messen Sie in solchen Fällen gegen eine lokale Build-Instanz.
Was Sie dabei aufgeben
Jede dieser Maßnahmen hat einen Preis. Weniger JavaScript heißt oft weniger Interaktivität. Drittanbieter-Skripte zu entfernen heißt, auf Daten oder Funktionen zu verzichten, die jemand im Marketing bewusst eingeführt hat. Diese Abwägungen gehören ausgesprochen — nicht still entschieden.
Wann Sie das Ergebnis sehen
Das Bewertungsfenster umfasst 28 Tage. Nach einem Deployment sehen Sie nach etwa einer Woche erste Bewegung und nach vier Wochen das vollständige Bild. Zwischenzeitliche Schwankungen sind normal und kein Anlass, weitere Änderungen nachzuschieben — sonst wissen Sie am Ende nicht, welche gewirkt hat.
Wie wir vorgehen
Wir beginnen mit Felddaten, nicht mit Lighthouse, und arbeiten die Tabelle oben von oben nach unten ab. Die vollständige Vorgehensweise steht in unserer technischen SEO-Checkliste; das Leistungsangebot unter technisches SEO und technisches Audit. Wenn die Ursache in der Architektur liegt, ist der Rahmen die Webentwicklung.
Wenn Ihre Search Console rote Werte zeigt und Sie wissen möchten, welche Ursache dahintersteckt: Schicken Sie uns die URL — Sie bekommen innerhalb von 48 Stunden eine Einschätzung mit der wahrscheinlichsten Ursache und dem geschätzten Aufwand.