Zum Inhalt springen

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

Titelgrafik im headon-Stil: Core Web Vitals: messen und verbessern

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):

  1. LCP (Largest Contentful Paint) – wie lange es dauert, bis das größte sichtbare Element geladen ist: meist das Hero-Bild oder die Hauptüberschrift.
  2. INP (Interaction to Next Paint) – wie schnell die Seite auf Klicks, Tipps und Tastatureingaben reagiert, gemessen über den gesamten Besuch.
  3. 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:

SeiteLCPMessung
rechnerzentrale.com0,55 sLighthouse Desktop
aphantasie.org0,69 sLighthouse Desktop
headon.pro (alte Version)3,0 sLighthouse 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:

UrsacheLösung
Bilder ohne width und heightMaße angeben, Seitenverhältnis reservieren
Nachträglich geladene BannerPlatzhalter mit fester Höhe
Webfonts, die die Textgröße ändernSchrift vorladen, passende Fallback-Schrift wählen
Cookie-Banner, das den Inhalt verschiebtAls Overlay oder fixiert am Rand anzeigen
Iframes ohne MaßeGröß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

Überarbeitet im September 2026.

Weiterlesen

Mehr aus dem Blog.

Alle Beiträge
  • 13 Min.

    BFSG-Checkliste 2026: barrierefreie Website

    BFSG Checkliste 2026 – prüfbare Barrierefreiheit nach WCAG 2.2 AA: Alt-Texte, Kontrast, Tastatur, Formulare, Online-Shop. Mit Beispielen und Erläuterungen.

    Web & Software

  • 12 Min.

    TypeSafe Jev: KI-Urteile in der Archäologie

    Was ein System-One-Modell anders macht als ein LLM, wo Jev in der Archäologie geholfen hat und wo es gescheitert ist – mit echten Antworten und Messwerten.

    KI · Fernerkundung

Passt das zu Ihrem Vorhaben?

Erzählen Sie uns, woran Sie arbeiten. Im Erstgespräch sagen wir, wie wir es angehen würden.