Core Web Vitals verbessern: Ein Praxisleitfaden

Seiten auf Position 1 bei Google bestehen die Core-Web-Vitals-Schwellenwerte 10 % häufiger als Seiten auf Position 9. Das klingt nach wenig — bis man bedenkt, dass der Unterschied zwischen Position 3 und Position 8 für ein KMU den Unterschied zwischen 200 und 20 Anfragen pro Monat bedeuten kann.

Core Web Vitals sind Googles Metriken für die reale Nutzererfahrung. Seit dem Core Update im März 2026 gewichtet Google Performance-Signale stärker als zuvor. Dieser Leitfaden zeigt die drei Metriken, ihre Schwellenwerte und — vor allem — die Maßnahmen mit dem größten Hebel.

Die drei Metriken auf einen Blick

Core Web Vitals messen drei Aspekte der Nutzererfahrung: Ladegeschwindigkeit (LCP), Reaktionsfähigkeit (INP) und visuelle Stabilität (CLS).

Metrik	Was sie misst	Gut	Schlecht
LCP — Largest Contentful Paint	Wie schnell der größte sichtbare Inhalt erscheint	≤ 2,5 s	> 4,0 s
INP — Interaction to Next Paint	Wie schnell die Seite auf Klicks/Taps reagiert	≤ 200 ms	> 500 ms
CLS — Cumulative Layout Shift	Wie stabil das Layout beim Laden bleibt	≤ 0,1	> 0,25

Wichtig: Google misst Felddaten — echte Nutzererfahrungen über den Chrome UX Report, nicht Labortests. Lighthouse-Scores sind nützlich zum Debuggen, aber Felddaten entscheiden über Ihr Ranking.

Zuerst: Haben Sie überhaupt Felddaten?

Die Frage klingt banal, entscheidet aber darüber, ob der Rest dieses Artikels für Sie überhaupt messbar ist. Der Chrome UX Report zeigt eine Website erst, wenn genug Besucher zusammenkommen, die Chrome nutzen und der Übermittlung von Nutzungsstatistiken zugestimmt haben. Wo genau die Schwelle liegt, veröffentlicht Google nicht — in der Praxis liegt ein großer Teil der Websites kleiner Unternehmen darunter.

Sie erkennen es sofort: Steht in PageSpeed Insights oben „Es sind nicht genügend Daten für eine Bewertung vorhanden”, gibt es für diese URL keine Felddaten. Manchmal erscheinen dann noch Werte für den Ursprung — die Domain als Ganzes, gemittelt über alle Seiten. Besser als nichts, aber es verrät nicht, welche Seite das Problem hat.

Daraus folgen drei Dinge:

Ohne Felddaten ist der Lighthouse-Score Ihre einzige Zahl — und er ist eine Simulation. Lighthouse lädt die Seite einmal, auf einer künstlich gedrosselten Verbindung, ohne dass jemand klickt. Er kann INP gar nicht messen und zeigt stattdessen die Total Blocking Time als Näherung. Zur Diagnose ist er ausgezeichnet. Als Zielgröße taugt er nicht.

Eigene Messwerte sind an einem Nachmittag aufgesetzt. Googles Bibliothek web-vitals misst im Browser echter Besucher und schickt das Ergebnis an einen eigenen Endpunkt:

import { onLCP, onINP, onCLS } from "web-vitals";

function senden(metrik) {
  navigator.sendBeacon("/api/vitals", JSON.stringify({
    name: metrik.name,          // "LCP" | "INP" | "CLS"
    wert: metrik.value,
    bewertung: metrik.rating,   // "good" | "needs-improvement" | "poor"
    pfad: location.pathname,
  }));
}

onLCP(senden);
onINP(senden);
onCLS(senden);

Damit sehen Sie Ihre eigenen Werte nach Tagen statt nach Wochen — und pro Seite statt pro Domain. Ein Hinweis, der in solchen Anleitungen meist fehlt: Wer so misst, verarbeitet Nutzungsdaten. Das gehört in die Datenschutzerklärung, und die Zuordnung zu einzelnen Personen sollte man gar nicht erst erheben.

Bis dahin gilt: Optimieren Sie die Ursachen, nicht die Zahl. Die Maßnahmen unten wirken unabhängig davon, ob jemand sie im Chrome UX Report ablesen kann.

Die richtige Reihenfolge: TTFB → LCP → INP → CLS

Bevor Sie einzelne Metriken optimieren: Arbeiten Sie in dieser Reihenfolge. TTFB (Time to First Byte) ist das Fundament — wenn der Server langsam antwortet, kann keine Optimierung das kompensieren.

Priorität	Metrik	Typischer Hebel
1	TTFB	CDN aktivieren, Server-seitig cachen
2	LCP	Bilder optimieren, kritische Ressourcen vorladen
3	INP	JavaScript reduzieren, Event-Handler schlank halten
4	CLS	Dimensionen setzen, Schriften vorladen

Und: Optimieren Sie auf Template-Ebene, nicht URL für URL. Ein Fix im Basis-Layout behebt das Problem auf allen Seiten, die dieses Template verwenden.

LCP optimieren: Die drei stärksten Hebel

Das Hero-Bild ist fast immer der LCP-Kandidat. Drei Maßnahmen sparen in meinen Projekten zusammen regelmäßig 1–2 Sekunden — aber erst, wenn klar ist, wo die Zeit überhaupt steckt.

Zuerst herausfinden, welcher Abschnitt zu lang ist

Ein LCP von 4 Sekunden sagt noch nicht, woran es liegt. Google zerlegt ihn in vier Abschnitte, und die richtige Maßnahme hängt davon ab, welcher davon dominiert:

Abschnitt	Was dort passiert	Wenn er der lange ist
Time to First Byte	Anfrage bis zum ersten Byte der HTML-Antwort	Hosting, Caching, CDN — das Bild ist unschuldig
Resource Load Delay	Zeit, bis der Browser das LCP-Bild überhaupt anfordert	Das Bild wird zu spät entdeckt: preload, fetchpriority, kein loading="lazy", kein CSS-Hintergrundbild
Resource Load Duration	Der Download des Bildes selbst	Format und Maße: WebP/AVIF, srcset, kleinere Datei
Element Render Delay	Bild ist da, wird aber noch nicht gezeichnet	Render-blockierendes CSS oder JS, ein Webfont, der den Text zurückhält

Bei einer typischen WordPress-Seite steckt die Zeit fast immer im TTFB und im Load Delay — nicht in der Dateigröße. Wer nur das Bild komprimiert, gewinnt ein paar hundert Millisekunden und wundert sich, dass der Wert steht.

Die Aufteilung lesen Sie in PageSpeed Insights im Abschnitt zum LCP-Element ab; in den Chrome DevTools zeigt sie das Performance-Panel.

1. Bildformat und Größe

Ein 5 MB großes Hero-Bild, das als 200 KB WebP funktionieren würde, ist der häufigste LCP-Killer. Die Lösung:

<img
  src="/hero.webp"
  alt="Beschreibung"
  width="1200"
  height="630"
  fetchpriority="high"
  loading="eager"
/>

• WebP/AVIF statt PNG/JPG — 30–50 % kleiner bei gleicher Qualität
• fetchpriority="high" signalisiert dem Browser: dieses Bild hat Vorrang
• Explizite width/height — verhindert Layout-Shifts und ermöglicht dem Browser, Platz zu reservieren

2. Render-blockierende Ressourcen eliminieren

Jede CSS- oder JS-Datei im <head> ohne async oder defer blockiert das Rendering. Moderne Frameworks wie Astro lösen das automatisch — bei WordPress mit 15+ Plugins lohnt ein Blick in den Netzwerk-Tab.

Schnelltest: Öffnen Sie Chrome DevTools → Network → filtern Sie nach „Render-blocking”. Alles, was dort rot markiert ist, verzögert Ihren LCP.

3. Server-Antwortzeit (TTFB) unter 200 ms bringen

Ein CDN wie Cloudflare kann die TTFB auf unter 50 ms drücken — bei statischen Websites der einfachste und wirkungsvollste Hebel. Für WordPress-Seiten: Server-seitiges Caching (WP Super Cache, WP Rocket) bringt ähnliche Ergebnisse.

INP verbessern: Das Problem heißt JavaScript

INP ist die am häufigsten versagte Core-Web-Vital-Metrik: 43 % aller Websites liegen über dem 200-ms-Schwellenwert. Der Grund: zu viel JavaScript im Main Thread.

Die drei Abschnitte einer Interaktion

Auch INP zerfällt in drei Teile, und auch hier entscheidet der dominierende Teil über die Maßnahme:

Abschnitt	Was dort passiert	Typische Ursache
Input Delay	Der Tap ist passiert, Ihr Handler läuft noch nicht	Der Main Thread ist mit anderem beschäftigt — meist Third-Party-Skripte oder ein langer Task beim Laden
Processing Duration	Ihre Event-Handler laufen	Zu viel Arbeit im Handler: Layout lesen und schreiben im Wechsel, große Listen, synchrone Renderings
Presentation Delay	Handler fertig, der Browser zeichnet noch nicht	Großer DOM-Baum, teure CSS-Effekte, aufwendiges Rendering

Das ist der Grund, warum der Ratschlag „weniger JavaScript” oft ins Leere läuft: Dominiert der Input Delay, hilft kein schlankerer Handler — dann muss die Arbeit weg, die vor dem Klick den Thread blockiert.

Welche Interaktion es trifft, verrät die Attribution-Variante derselben Bibliothek:

import { onINP } from "web-vitals/attribution";

onINP(({ value, attribution }) => {
  console.log(value, {
    element: attribution.interactionTarget,   // CSS-Selektor des Elements
    art: attribution.interactionType,         // "pointer" | "keyboard"
    inputDelay: attribution.inputDelay,
    verarbeitung: attribution.processingDuration,
    darstellung: attribution.presentationDelay,
  });
});

Der Wert von interactionTarget ist der Punkt, an dem die Suche anfängt — statt im ganzen Bundle zu raten.

Drei Maßnahmen, die den größten Unterschied machen:

Third-Party-Scripts auditieren. Analytics, Chat-Widgets, Tag-Manager und Social-Media-Embeds sind die üblichen Verdächtigen. In einem kürzlichen Projekt hat das Entfernen eines ungenutzten Intercom-Widgets den INP von 380 ms auf 120 ms gesenkt — eine einzelne Zeile Code.

Event-Handler schlank halten. Aufwendige Berechnungen gehören nicht in Click-Handler. Lagern Sie rechenintensive Arbeit in requestIdleCallback oder Web Worker aus.

content-visibility: auto auf langen Seiten. Diese CSS-Eigenschaft sagt dem Browser: Rendere nur, was sichtbar ist. Bei Seiten mit 20+ Abschnitten kann das den INP halbieren.

.section-below-fold {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

CLS vermeiden: Meistens einfach zu beheben

CLS-Probleme sind die am einfachsten zu behebenden — weil die Ursachen fast immer dieselben sind:

Bilder und Videos ohne Dimensionen. Das Element lädt, alles verschiebt sich. Fix: Immer width und height im HTML setzen. Der Browser reserviert den Platz, bevor das Bild da ist.

Webfonts ohne Fallback-Strategie. Text springt, wenn der Custom Font den System-Font ersetzt. Fix:

@font-face {
  font-family: "Inter";
  font-display: swap;
  src: url("/fonts/inter.woff2") format("woff2");
}

Noch besser: font-display: optional — der Custom Font wird nur gezeigt, wenn er rechtzeitig geladen ist. Kein Sprung, kein Flash.

Dynamisch eingefügte Inhalte. Cookie-Banner, Sticky-Header und Werbebanner sind CLS-Klassiker. Reservieren Sie den Platz vorab mit fester Höhe oder verwenden Sie position: fixed / position: sticky, um den Dokumentenfluss nicht zu stören.

Der Hebel, den fast alle übersehen: bfcache

Navigiert ein Besucher zurück, kann Chrome die vorherige Seite vollständig aus dem Back-Forward-Cache wiederherstellen — mitsamt JavaScript-Zustand, in wenigen Millisekunden. Für diese Navigation sind LCP und CLS praktisch null. Viele Seiten schließen sich davon selbst aus, fast immer unabsichtlich:

• ein unload-Event-Listener (veraltet und ein zuverlässiger bfcache-Blocker — pagehide nutzen)
• Cache-Control: no-store auf dem HTML-Dokument
• eine offene WebSocket-Verbindung oder IndexedDB-Transaktion im falschen Moment

Prüfen: Chrome DevTools → Application → Back/forward cache → „Test back/forward cache”. Chrome nennt den Blockierungsgrund im Klartext, inklusive der verursachenden Stelle.

Messen: Drei Werkzeuge reichen

Für den Anfang brauchen Sie nicht mehr als das:

1. PageSpeed Insights — zeigt Felddaten (echte Nutzer) und Labordaten in einem Report. Die Felddaten-Sektion oben ist das, was Google tatsächlich für Rankings nutzt.
2. Chrome DevTools → Performance — für die frame-genaue Analyse einzelner Interaktionen. Unverzichtbar für INP-Debugging, und die einzige Stelle, an der Sie einen langen Task tatsächlich einer Funktion zuordnen können.
3. web-vitals im eigenen Frontend — für Seiten, die zu wenig Verkehr für den Chrome UX Report haben, oder wenn Sie eine Änderung nicht sechs Wochen lang beobachten wollen.

Optimieren Sie für echte Nutzer, nicht für Lighthouse-Scores. Ein Score von 95 mit schlechten Felddaten hilft nicht beim Ranking. Felddaten aus dem Chrome UX Report sind aussagekräftiger als jeder Lab-Test.

Häufige Fragen zu Core Web Vitals

Reichen gute Core Web Vitals allein für ein Top-Ranking?

Nein. Content-Relevanz und Domain-Autorität wiegen schwerer. Googles John Mueller hat das mehrfach bestätigt: „Relevance is still by far much more important.” Aber bei gleichwertigen Inhalten entscheiden Core Web Vitals über Position 3 vs. Position 8 — und das ist ein enormer Traffic-Unterschied.

Wie schnell wirken sich Verbesserungen aus?

Felddaten im Chrome UX Report werden über 28 Tage gerollt. Nach einem Fix dauert es also 4–6 Wochen, bis Google die Verbesserung sieht. Keine Panik, wenn sich nach zwei Wochen noch nichts tut.

Gelten Core Web Vitals auch für Desktop?

Ja, aber Google nutzt seit 2024 primär Mobile-Felddaten als Ranking-Signal — auch für Desktop-Ergebnisse. Optimieren Sie zuerst für Mobile.

PageSpeed Insights zeigt keine Felddaten. Was jetzt?

Dann hat Ihre Seite zu wenig Chrome-Besucher für den Chrome UX Report — bei kleinen Unternehmenswebsites der Normalfall, kein Fehler. Prüfen Sie, ob wenigstens Ursprungsdaten für die Domain angezeigt werden, arbeiten Sie ansonsten mit dem Lighthouse-Bericht zur Diagnose und messen Sie parallel mit web-vitals bei Ihren eigenen Besuchern. Für das Ranking bedeutet fehlende Datenlage übrigens keinen Nachteil: Google fällt dann auf Ursprungsdaten zurück.

Origin-Daten oder URL-Daten — was zählt?

Liegen für die einzelne URL genug Daten vor, werden diese verwendet; sonst greift Google auf die Werte des gesamten Ursprungs zurück. Praktische Folge: Eine langsame, stark besuchte Seite zieht bei kleinen Websites die Bewertung aller anderen Seiten mit nach unten. Das ist auch der Grund, warum sich Optimierung am Template mehr lohnt als an einer einzelnen URL.

Mein INP liegt bei 250 ms. Muss ich sofort handeln?

250 ms ist „verbesserungswürdig”, nicht „schlecht” — kein Notfall, aber ein Hinweis. Sehen Sie zuerst nach, welcher der drei Abschnitte den Wert treibt. Dominiert der Input Delay, liegt es meist an Skripten Dritter, und dann ist die Frage weniger technisch als geschäftlich: Was bringt das Chat-Widget, das jeden Erstklick um 200 ms verzögert?

Was bleibt

Core Web Vitals sind kein Mysterium und kein Fulltime-Job. Mit den richtigen Bildformaten, schlankem JavaScript und sauberem Layout-Handling sind grüne Werte in den meisten Fällen innerhalb weniger Stunden erreichbar.

Die Kurzformel: schnell laden (LCP ≤ 2,5 s), schnell reagieren (INP ≤ 200 ms), nicht springen (CLS ≤ 0,1). Wenn Sie wissen wollen, was eine schnellere Website für Ihr Geschäft bedeutet, sprechen Sie mich auf eine Performance-Analyse an.