Core Web Vitals 2026: Der verständliche Leitfaden für Nicht-Techniker

„Unsere Website ist langsam" — diesen Satz höre ich in gefühlt der Hälfte aller Erstgespräche. Was dahinter steckt, sind fast immer die Core Web Vitals: drei Google-Metriken, die seit 2021 das Ranking beeinflussen und seit 2024 in der aktuellen Form (mit INP statt FID) gelten.

Dieser Artikel erklärt sie ohne Entwickler-Jargon — und zeigt dir, wo du ansetzen kannst.

Warum Core Web Vitals wichtig sind

Die wichtigste Zahl aus der Tabelle: Nur 38 % der mobilen Websites weltweit bestehen alle drei Core Web Vitals. Das heißt: Wer sie schafft, ist in der oberen Hälfte — oft sogar im oberen Drittel. Das ist SEO-bare Bar, die sich lohnt.

Die drei Vitals im Klartext

LCP — Largest Contentful Paint

Was es misst: Wie schnell das größte sichtbare Element auf der Seite geladen ist. Das ist meistens das Hero-Bild oder die Hero-Überschrift.

Schwellenwert „gut": unter 2,5 Sekunden.

Typische Killer:

• Zu großes, unkomprimiertes Hero-Bild
• Web-Fonts, die den Text blockieren
• Server-Antwortzeit (TTFB) über 600 ms
• JavaScript, das Bilder erst lädt, nachdem es selbst geladen ist

INP — Interaction to Next Paint

Was es misst: Wie schnell die Seite auf Interaktionen reagiert (Klicks, Scrolls, Taps). Der schlechteste Wert aus allen Interaktionen deiner Session wird genommen.

Schwellenwert „gut": unter 200 ms.

Typische Killer:

• Schwere JavaScript-Frameworks (Client-Side Rendering ohne Optimierung)
• Viele gleichzeitige Third-Party-Scripts (Analytics, Ads, Chatbots)
• Komplexe Hover/Click-Handler, die nicht optimiert sind

CLS — Cumulative Layout Shift

Was es misst: Wie oft sich während des Ladens das Layout verschiebt. Das nervtötende „Ich wollte auf den Button klicken, aber der ist weggerutscht"-Problem.

Schwellenwert „gut": unter 0,1 (dimensionsloser Wert).

Typische Killer:

• Bilder ohne feste width/height-Angabe
• Web-Fonts mit anderen Proportionen als die Fallback-Fonts
• Dynamische Anzeigen, die sich nach dem Laden einblenden
• Cookie-Banner, die Layout verschieben statt darüber zu liegen

Mobile vs. Desktop — warum das einen Unterschied macht

Die Zahlen kommen aus dem aktuellen HTTP Archive Web Vitals Report (Q1/2026). Der Abstand zwischen Mobile und Desktop ist strukturell:

• Mobile CPUs sind langsamer (Median-Smartphone ist ungefähr ein Low-End-Laptop)
• Mobile Netzwerke haben höhere Latenzen und schwankende Bandbreiten
• Mobile Viewports zeigen mehr vom „ersten Fold" auf einmal, der LCP-Kandidat ist oft größer

Konkret: Wenn du nur auf Desktop testest, unterschätzt du dein Problem um ~30 %. Mobile-First-Testing ist Pflicht.

Wo du am meisten Hebel hast

Die Prozentangaben stammen aus Messungen in eigenen Projekten — typische Verbesserungen, wenn eine einzelne Maßnahme isoliert umgesetzt wird. Die Summe ist nicht additiv (Effekte überlagern sich), aber die Reihenfolge gibt die Priorität.

1. Bilder — fast immer die Nummer 1

• Alle Bilder in WebP (oder AVIF) statt JPEG/PNG: 30–50 % kleiner bei gleicher Qualität
• Responsive Images mit srcset und sizes: kein 2000-px-Bild für ein 400-px-Display
• Lazy-Loading für alles unter dem Fold: <img loading="lazy" />
• Feste width/height-Angaben gegen Layout-Shift
• Preload für das Hero-Bild: <link rel="preload" as="image" href="…" />

2. Fonts — der unterschätzte Hebel

• Nur 1–2 Font-Familien laden (nicht 5 aus Marketing-Gründen)
• font-display: swap — zeigt Fallback-Font, bis Custom geladen ist
• Subset der benötigten Glyphen (nicht jeder braucht chinesische Zeichen)
• Lokales Hosting statt Google-Fonts-CDN — schneller und DSGVO-sauber

3. Third-Party-Scripts — die stillen Killer

Google Analytics, Facebook-Pixel, YouTube-Embeds, Chatbots, Tag-Manager: Jedes Script zählt. Zwei Strategien:

• Async / Defer: Scripts laden parallel, blockieren nicht
• On-Demand: Scripts erst laden, wenn sie gebraucht werden (Consent-Klick, Scroll-in-View)

Der praktische Test-Workflow

Schritt 1: Daten sammeln

1. PageSpeed Insights für deine wichtigsten URLs (Homepage, 2–3 Unterseiten)
2. Google Search Console → „Core Web Vitals"-Tab für den 28-Tage-Durchschnitt
3. Screenshots speichern — für Vorher-Nachher-Vergleich

Schritt 2: Priorisieren

Welche Metrik ist rot/amber? Welche Seite ist am schlechtesten? Meistens gibt es 1–2 URLs, die die gesamte CrUX-Statistik ziehen — dort zuerst ansetzen.

Schritt 3: Maßnahmen umsetzen

In der Reihenfolge oben: Bilder → Fonts → Third-Party → kritisches CSS.

Schritt 4: Monitoring

Nach 3–4 Wochen neue Feld-Daten checken. Geduld haben — Google aktualisiert die CrUX-Daten langsam.

Typische Stolpersteine

• „Mein Lighthouse-Score ist 95, aber die Feld-Daten sind rot" — das liegt am Hardware-Spread realer User. Dein Testgerät ist schneller als der Durchschnitt.
• „Nach der Optimierung hat sich nichts geändert" — Feld-Daten brauchen 3–4 Wochen, um die Verbesserung widerzuspiegeln.
• „Ich habe alle Bilder optimiert, LCP ist trotzdem langsam" — dann liegt's an der Server-Antwortzeit oder am kritischen Pfad-CSS.

Mein Fazit

Core Web Vitals sind keine Raketenwissenschaft. Mit einem strukturierten Vorgehen sind 1–2 Tage Arbeit realistisch, um eine durchschnittliche Business-Website von amber/rot auf grün zu bringen. Die schwierigen Fälle sind Shops mit viel Drittanbieter-Code (Payment, Personalisierung, Analytics) — da kann es Wochen dauern.

Wichtig: Die Investition zahlt sich doppelt aus. Besseres Google-Ranking + geringere Absprungrate + mehr Conversion. Langsame Seiten haben messbar höhere Bounce-Raten (laut Google: +32 % bei jeder zusätzlichen Sekunde Ladezeit).

Wenn du konkret wissen willst, wo deine Hebel liegen — ich mache einen kostenfreien PageSpeed-Check. 30 Minuten Screenshare, klare Priorisierung, keine Verkaufsgespräche.