Zum Inhalt springen
Tagleuchte
← Blog·Web Performance··14 Min Lesezeit

Core Web Vitals 2026 — was wirklich zählt

Core Web Vitals sind drei messbare Kennzahlen, mit denen Google die Nutzererfahrung einer Website bewertet — Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS). Wer im organischen Ranking konkurrieren und Conversions nicht verlieren will, muss alle drei in den „good“-Bereich bringen. Dieser Artikel erklärt was zählt, wo die Schwellen liegen und welche Hebel 2026 wirklich Wirkung zeigen.

Von Andrea Otten·Geschäftsführerin · Tagleuchte

Was sind Core Web Vitals?

Core Web Vitals sind ein Set aus drei Kennzahlen, mit denen Google die Nutzererfahrung einer Website misst. Sie wurden 2020 als Teil des Page-Experience-Signals eingeführt und seit dem mehrfach überarbeitet — zuletzt im März 2024, als Interaction to Next Paint (INP) das alte First Input Delay (FID) ersetzt hat.

Die drei aktuellen Metriken: LCP (Ladezeit des größten sichtbaren Elements), INP (Reaktionszeit auf Interaktionen) und CLS (visuelle Stabilität). Jede hat einen klaren „good“-Schwellenwert. Sites, die alle drei in „good“ halten, ranken besser und konvertieren stärker.

Warum sie 2026 mehr zählen denn je

Drei Entwicklungen erhöhen den Druck. Erstens: Mobile-First- Indexing ist seit 2023 Standard — Google bewertet ausschließlich die mobile Version. Mobile-Latenz (3G, 4G, schwache LTE) ist deutlich strenger als Desktop-Bedingungen.

Zweitens: Wettbewerb. Marketing-Sites von Großkonzernen werden seit 2022 systematisch performance-optimiert. Wer 2026 noch bei 4 Sekunden LCP liegt, sieht im SERP für umkämpfte Begriffe alt aus.

Drittens: Conversions. Studien von Akamai, Cloudflare und Google selbst zeigen Conversion-Verluste von rund 7 Prozent pro 100 Millisekunden zusätzlicher Ladezeit. Auf einer Marketing-Site mit 10.000 monatlichen Besuchen sind das schnell mehrstellige Umsatzverluste — unabhängig vom Ranking-Faktor.

LCP — Largest Contentful Paint

Schwelle: < 2,5 s good · < 4 s needs improvement

Die Zeit, bis das größte sichtbare Element des initialen Viewport vollständig gerendert ist — meist ein Hero-Bild oder eine Headline. Misst, wie schnell die Seite ‚wirklich da' ist.

Häufige Ursachen
  • ·Langsame Server-Antwort (TTFB > 600 ms)
  • ·Render-blocking CSS oder JavaScript im Critical Path
  • ·Unoptimierte Bilder (PNG statt AVIF, kein srcset, keine width/height)
  • ·Zu viele Web-Fonts ohne display: swap
  • ·Drittanbieter-Scripts vor dem Hero (z.B. Tag Manager)
Konkrete Fixes
  • Hero-Bild als next/image priority + AVIF + sizes
  • Fonts self-hosten via next/font/local, display: swap
  • Critical CSS inline, Rest deferred
  • TTFB unter 200 ms via Edge-Caching oder ISR
  • Drittanbieter-Tags asynchron oder verzögert laden

INP — Interaction to Next Paint

Schwelle: < 200 ms good · < 500 ms needs improvement

Misst die Latenz zwischen einer Nutzer-Interaktion (Klick, Tap, Tastendruck) und dem nächsten visuellen Update. Im Gegensatz zum alten FID berücksichtigt INP alle Interaktionen einer Sitzung — nicht nur die erste.

Häufige Ursachen
  • ·Long-Running JavaScript-Tasks im Main-Thread (> 50 ms)
  • ·Schwere Hydration nach Page-Load
  • ·React-Re-Renders mit ineffizienten Listen
  • ·Synchrone XHR / fetch-Calls auf Klick
  • ·Drittanbieter-Scripts mit Main-Thread-Blockern
Konkrete Fixes
  • Server Components für alles, was nicht Interaktion braucht
  • Lange Tasks in requestIdleCallback oder Web Worker auslagern
  • useTransition() für teure State-Updates
  • Lazy-Loading für nicht-kritische Komponenten via next/dynamic
  • Tag-Manager und Analytics nach dem ‚load'-Event laden

CLS — Cumulative Layout Shift

Schwelle: < 0,1 good · < 0,25 needs improvement

Summe aller unerwarteten Layout-Verschiebungen während des Page-Lifecycles. Niedrig = visuell stabil. Häufige Übeltäter: Bilder ohne Dimensions, Embeds, dynamisch eingefügte Werbung oder Cookie-Banner.

Häufige Ursachen
  • ·<img> ohne width und height
  • ·Embeds (YouTube, Twitter, Maps) ohne Aspect-Container
  • ·Dynamisch nachgeladener Content über bereits sichtbarem Inhalt
  • ·Web-Fonts ohne size-adjust-Fallback (Font-Switching)
  • ·Cookie-Banner, der nach Page-Load Layout pusht
Konkrete Fixes
  • Allen Bildern explizite width/height oder aspect-ratio im CSS
  • Embeds in Container mit aspect-ratio-Property
  • Skeleton-States statt nachträglich eingefügter Inhalte
  • Font-Fallback mit ascent-override / size-adjust
  • Cookie-Banner als Overlay (nicht Layout-pushend)

Wie Sie Ihre Werte messen

Drei Quellen kombinieren — keine reicht alleine:

  • 01PageSpeed Insights (pagespeed.web.dev) — Field-Daten aus dem Chrome UX Report plus Lab-Test in einem. Beste Erstanlaufstelle.
  • 02Search Console — Core Web Vitals: Felddaten aggregiert pro URL-Gruppe. Zeigt schwache Cluster, die im PSI-Einzeltest nicht auffallen.
  • 03web-vitals-Library für eigenes Real-User-Monitoring. Liefert Werte aus dem realen Traffic ins eigene Analytics-Backend, mit voller URL- und Device-Granularität.

Optional in der Pull-Request-Pipeline: Lighthouse-CI mit fixem Budget — bricht Builds, die Schwellen verletzen. Vermeidet Performance- Regressions, die erst im Live-Betrieb auffallen.

Sechs konkrete Optimierungs-Hebel

Sortiert nach Impact pro Aufwand. Wer einen einzigen Hebel setzen kann: Hero-Bild als priority + AVIF. Spart auf vielen Seiten 1 bis 2 Sekunden LCP — in einem Atemzug.

  1. 01

    Hero-Bild als priority + AVIF

    Das LCP-Element ist auf den meisten Seiten das große Hero-Bild oder die Headline-Schrift. Bei Bildern: <Image priority /> in next/image, AVIF-Format (40 % kleiner als WebP), passende sizes-Property, korrekte width/height. Pre-Connect zum Bild-Host im <head>, falls extern.

  2. 02

    Fonts self-hosten + display:swap

    Google-Fonts-CDN ist langsamer als ein eigener Server, plus DSGVO-Risiko. Self-hosting via next/font/local, display:swap, und nur die zwei wichtigsten Weights preloaden. Variable Fonts ersparen drei Datei-Requests.

  3. 03

    JavaScript-Bundle unter 170 kB gzip

    Jedes ungenutzte Kilobyte JavaScript verzögert Hydration und damit INP. Tree-shake aggressive (auch Barrel-Exports), nutze next/dynamic für nicht-kritische Komponenten (Cursor, Lenis, Modal-Inhalte), und prüfe regelmäßig mit Bundle-Analyzer.

  4. 04

    Layout-Shift verhindern: width × height auf allen Bildern

    CLS bricht durch fehlende Reservierungen ein: Bilder ohne Dimensions, Embeds in floating Containers, dynamisch eingefügter Content. Jede <img> bekommt width und height (oder aspect-ratio im CSS). next/image macht das automatisch — die HTML-Bilder im Content-Bereich nicht.

  5. 05

    Long-Tasks brechen, Hydration entzerren

    INP misst die Reaktionszeit auf Interaktionen. Lange JavaScript-Tasks blockieren den Main-Thread. Trick: requestIdleCallback für nicht-kritische Initialisierung, Web Workers für schwere Berechnungen, oder schlicht: weniger JS auf dem kritischen Pfad. Server Components helfen dramatisch.

  6. 06

    Edge-Caching + ISR statt Server-Render

    Static-Site-Generation oder Incremental Static Regeneration (ISR) auf Vercel-Edge bedeutet: HTML kommt in unter 100 Millisekunden global. SSR pro Request ist deutlich langsamer. Wer dynamische Daten braucht: server actions plus suspense für selektives Streaming.

Quellen & weiterführend
Mehr zum Thema

Performance ist ein Teilbereich von gutem Webdesign — die vollständige Sicht auf Konzept, Build und Hosting findet sich auf unserer Cornerstone-Seite zur Webdesign-Agentur Mannheim. Wer wissen will, wie sich Performance auf SEO-Rankings auswirkt, liest die OnPage-SEO-Checkliste 2026.

Über die Autorin

Andrea Otten ist Geschäftsführerin · Tagleuchte. Sie betreut Webprojekte mit Fokus auf Performance und SEO seit über zehn Jahren — von kleinen Marketing-Sites bis zu Konzern-Plattformen.

Häufige Fragen zu Core Web Vitals

  • Sind Core Web Vitals 2026 noch ein Ranking-Faktor?

    Ja. Google hat Core Web Vitals als Teil des Page-Experience-Signals bestätigt — sie sind kein dominanter Hebel, aber bei vergleichbarer Inhaltsqualität entscheiden sie. Wichtiger: schlechte Werte verschlechtern UX direkt, Konversionen sinken messbar. Auch ohne Ranking-Effekt lohnt sich die Optimierung.

  • Wie messe ich Core Web Vitals zuverlässig?

    Drei Quellen kombinieren: Google PageSpeed Insights für Field-Daten (echte Nutzer-Erfahrung aus Chrome UX Report), Lighthouse für Lab-Daten (kontrollierte Synthetik-Tests), Search Console Core-Web-Vitals-Bericht für URL-Granularität. Real-User-Monitoring via Web-Vitals-Library für eigene Live-Daten.

  • Was ist der Unterschied zwischen Field- und Lab-Daten?

    Lab-Daten sind synthetische Tests in einer kontrollierten Umgebung — z.B. Lighthouse mit fixer Bandbreite. Field-Daten kommen aus dem CrUX-Report: anonymisierte echte Nutzer-Werte aus Chrome. Lab-Daten sind reproduzierbar, Field-Daten sind die Realität. Google rankt nach Field-Daten.

  • Warum hat INP 2024 das alte FID abgelöst?

    First Input Delay (FID) hat nur den ersten Klick gemessen — aber spätere Interaktionen können viel langsamer sein. Interaction to Next Paint (INP) misst die schlechteste Interaktion einer ganzen Sitzung und reflektiert damit reale Nutzer-Frustration besser. Seit März 2024 offizieller Core-Web-Vitals-Bestandteil.

  • Welcher LCP-Wert ist gut für 2026?

    Google nennt 2,5 Sekunden als Schwelle für „good“, 4 Sekunden für „needs improvement“. Realistisches Ziel für moderne Websites: unter 1,8 Sekunden auf Mobile, unter 1,2 Sekunden auf Desktop. E-Commerce- und News-Wettbewerber liegen oft unter 1,5 Sekunden.

  • Lohnt sich Performance-Optimierung für eine Marketing-Website?

    Ja, doppelt: organische Rankings profitieren leicht, aber Conversions stark. Studien (Google, Akamai, Cloudflare) zeigen Conversion-Verluste von rund 7 Prozent pro 100 Millisekunden zusätzlicher Ladezeit. Bei einer Marketing-Site mit 10.000 Besuchen pro Monat sind das schnell mehrstellige Umsatzverluste.

  • Reicht eine schnelle Server-Antwort, oder muss ich auch Bilder optimieren?

    Bilder sind in 70 bis 80 Prozent der Fälle das LCP-Element auf Marketing-Sites. Eine 200-Millisekunden-TTFB nützt nichts, wenn das Hero-Bild 2 Megabyte hat. Optimierung an beiden Enden: Server-Antwort schnell halten, Bilder klein und im richtigen Format ausliefern.

  • Wie oft sollte ich Core Web Vitals monitoren?

    Wöchentliche Stichprobe in PageSpeed Insights und Search Console reicht für die meisten Sites. Bei aktiver Entwicklung: Lighthouse-CI in der Pull-Request-Pipeline einbauen, sodass jede Änderung automatisch geprüft wird. Real-User-Monitoring permanent, mit Alarm bei Abweichungen über 10 Prozent.

Wir bringen Ihre Core Web Vitals in den grünen Bereich.

Wir prüfen Ihre Site, identifizieren die drei größten Performance-Hebel und liefern eine schriftliche Einschätzung in zwei Werktagen — kostenlos, ohne Verkaufsgespräch.