Web & Software
Core Web Vitals: messen und verbessern
Core Web Vitals sind Google-Rankingfaktor. LCP, INP und CLS verstehen, messen und verbessern – mit den Zielwerten von Google und eigenen Messwerten.
9 Min. LesezeitOnur CirakogluAktualisiert

Core Web Vitals sind drei Messwerte, mit denen Google die Nutzererfahrung einer Seite bewertet: Wie schnell ist der Hauptinhalt da, wie schnell reagiert die Seite auf Eingaben, wie stabil bleibt das Layout beim Laden. Seit 2021 fließen sie in das Ranking ein. Dieser Guide erklärt die drei Werte, ihre häufigsten Ursachen und wie Sie sie messen und verbessern – ohne Zahlen, die wir nicht belegen können.
Was Core Web Vitals sind
Google misst drei Aspekte, und zwar an echten Nutzern (Chrome UX Report) sowie im Labor (Lighthouse):
- LCP (Largest Contentful Paint) – wie lange es dauert, bis das größte sichtbare Element geladen ist: meist das Hero-Bild oder die Hauptüberschrift.
- INP (Interaction to Next Paint) – wie schnell die Seite auf Klicks, Tipps und Tastatureingaben reagiert, gemessen über den gesamten Besuch.
- CLS (Cumulative Layout Shift) – wie stark sich das Layout während des Ladens verschiebt.
Googles Zielwerte („gut“)
Quelle: web.dev/vitals, abgerufen September 2026
- LCP – Hauptinhalt sichtbar
- 2.5s
- INP – Reaktion auf Eingabe
- 200ms
- CLS – Layout-Verschiebung
- 0.1
- der Seitenaufrufe müssen den Wert erreichen
- 75%
Der letzte Wert wird oft übersehen: Google bewertet das 75. Perzentil, getrennt für Mobil und Desktop. Es reicht nicht, dass die Seite auf einem schnellen Rechner im Büro gut aussieht. Drei von vier Aufrufen müssen den Zielwert erreichen – auch auf älteren Smartphones im Mobilfunknetz.
LCP: Wann ist der Hauptinhalt da?
Für Besucher ist der LCP der Moment, in dem die Seite „steht“. Die typischen Ursachen für schlechte Werte:
Zu große Bilder. Ein Hero-Bild in Originalauflösung, als JPEG statt AVIF oder WebP, ohne passende Größen für kleine Bildschirme.
Langsamer Server. Überlastetes Shared Hosting, kein Cache, Server weit vom Nutzer entfernt. Als Richtwert nennt Google für die Server-Antwortzeit (TTFB) „gut“ bis 0,8 s und „schlecht“ über 1,8 s.
Falsche Reihenfolge. Das Hero-Bild lädt erst, nachdem Schriften, Tracking-Scripts und ein Chat-Widget durch sind.
Was erreichbar ist: unsere eigenen Seiten
Wir messen unsere eigenen Projekte mit denselben Werkzeugen. Die Werte stammen aus Lighthouse-Läufen vom 24.09.2026 – es sind Laborwerte, überwiegend Desktop. Für das Ranking zählen die Felddaten echter Nutzer; die Tabelle zeigt also nur, was unter Laborbedingungen erreichbar ist:
| Seite | LCP | Messung |
|---|---|---|
| rechnerzentrale.com | 0,55 s | Lighthouse Desktop |
| aphantasie.org | 0,69 s | Lighthouse Desktop |
| headon.pro (alte Version) | 3,0 s | Lighthouse mobil |
Die dritte Zeile ist absichtlich dabei: Unsere eigene alte Website lag über dem Zielwert. Das war einer der Gründe für den Relaunch. Die neue Version misst ihre Ladezeit live im Footer – Sie können den Wert dort gerade jetzt sehen.
INP: Reagiert die Seite?
INP misst, wie lange es von einer Eingabe bis zur nächsten sichtbaren Reaktion dauert – über alle Interaktionen eines Besuchs, nicht nur die erste. Der Wert hat im März 2024 den älteren FID (First Input Delay) abgelöst und erfasst alle Interaktionen statt nur die erste.
Die häufigsten Ursachen:
- Zu viel JavaScript, das den Hauptthread blockiert: aufgeblähte Frameworks, ungenutzte Plugins.
- Drittanbieter-Scripts: Analytics, Werbe-Tracker, Chat-Widgets, Social-Buttons, die synchron laden.
- Schwache Geräte: Was auf dem Entwickler-Laptop flüssig läuft, ruckelt auf einem drei Jahre alten Smartphone.
INP verbessern
Ursachen
- Mehrere Tracking-Tools parallel
- Chat-Widget lädt sofort beim Seitenaufruf
- Große Bibliotheken für kleine Funktionen
- Lange Aufgaben im Hauptthread
Maßnahmen
- Scripts entfernen, die niemand auswertet
- Widgets erst bei Interaktion nachladen
- Code aufteilen, nur Nötiges laden
- Auf gedrosselter CPU in den DevTools testen
CLS: Bleibt das Layout stehen?
Jeder kennt es: Man will einen Link klicken, kurz vorher springt die Seite, und der Klick landet auf einer Anzeige. Genau das misst CLS.
Die üblichen Verdächtigen und ihre Lösungen:
| Ursache | Lösung |
|---|---|
Bilder ohne width und height | Maße angeben, Seitenverhältnis reservieren |
| Nachträglich geladene Banner | Platzhalter mit fester Höhe |
| Webfonts, die die Textgröße ändern | Schrift vorladen, passende Fallback-Schrift wählen |
| Cookie-Banner, das den Inhalt verschiebt | Als Overlay oder fixiert am Rand anzeigen |
| Iframes ohne Maße | Größe explizit setzen |
Messen: die richtigen Werkzeuge
Ohne Messung keine Verbesserung. Drei kostenlose Werkzeuge reichen:
PageSpeed Insights zeigt Felddaten echter Nutzer (falls genug Traffic vorhanden) und einen Laborlauf mit konkreten Vorschlägen. Der richtige Einstieg.
Google Search Console listet unter „Core Web Vitals“ alle URLs Ihrer Website mit ihrem Status. Das Werkzeug für laufendes Monitoring.
Chrome DevTools zeigt im Detail, welches Element den LCP bildet, welches Script blockiert und welche Elemente springen. Für die technische Ursachensuche.
Aktionsplan
Woche 1: Bestandsaufnahme und schnelle Erfolge
- Die fünf wichtigsten URLs in PageSpeed Insights messen, Werte notieren
- Bilder in AVIF oder WebP umwandeln und auf Anzeigegröße skalieren
- Ungenutzte Plugins und Scripts entfernen
- Erneut messen und dokumentieren
Woche 2 bis 4: Ursachen beheben
- Server-Antwortzeit (TTFB) prüfen; liegt sie über 0,8 s, Hosting oder Caching ändern
- Drittanbieter-Scripts verzögert laden oder streichen
- Bild- und Iframe-Maße setzen, Schriften vorladen
- Mobil gesondert testen
Danach: Überwachen
- Monatlicher Blick in die Search Console
- Nach jeder größeren Änderung an der Website neu messen
Performance ist keine Einmalaktion. Jede neue Bildergalerie, jedes neue Plugin kann die Werte wieder verschlechtern.
Häufig gestellte Fragen
Welche Werte sind gut?
LCP unter 2,5 s, INP unter 200 ms, CLS unter 0,1 – jeweils für 75 % der Aufrufe. Zwischen „gut“ und „schlecht“ liegt bei Google ein Bereich „verbesserungswürdig“ (LCP bis 4 s, INP bis 500 ms, CLS bis 0,25).
Wie schnell wirken Verbesserungen?
In PageSpeed Insights sofort. Die Felddaten in der Search Console basieren auf einem Zeitraum von 28 Tagen und ziehen entsprechend nach.
Geht das auch mit WordPress oder Shopify?
Ja. Bildoptimierung, weniger Plugins, Caching und ein besseres Hosting wirken auf jeder Plattform. Grenzen gibt es bei Themes und Baukästen, die viel JavaScript mitbringen – dann hilft nur ein schlankerer Unterbau.
Was ist der größte einzelne Hebel?
Fast immer die Bilder. Danach Drittanbieter-Scripts, danach Hosting.
Wie wir damit umgehen
Bei headon messen wir vor dem Launch und danach, und die Werte unserer eigenen Seiten stehen oben in diesem Beitrag. Wer wissen will, wo die eigene Website steht, bekommt mit dem kostenlosen SEO-Check eine erste Einordnung – Ladezeit und technische Basis inklusive.
Quellen
- web.dev: Web Vitals – Definition, Zielwerte, 75. Perzentil
- web.dev: Time to First Byte – Richtwerte für die Server-Antwortzeit
- Chrome UX Report – Felddaten
- PageSpeed Insights
Überarbeitet im September 2026.