Core Web Vitals 2026 einfach erklärt

Seit 2021 sind die Core Web Vitals ein offizieller Google-Rankingfaktor. Seit 2024 ersetzt INP (Interaction to Next Paint) den älteren FID (First Input Delay), und seit 2025 zählen die Werte zunehmend nicht nur bei Mobile, sondern auch bei Desktop. Wer 2026 noch eine Website mit roten Web-Vitals betreibt, lässt SEO-Potenzial liegen – und verliert direkt Conversions, weil langsame Seiten messbar weniger Anfragen produzieren.

Dieser Artikel erklärt die drei Metriken so verständlich wie möglich, zeigt die Zielwerte, die häufigsten Probleme und konkrete Lösungsschritte. Am Ende weißt du, wie du deine Werte misst, interpretierst und nachhaltig verbesserst.

Die drei Core Web Vitals im Überblick

LCP: Largest Contentful Paint

LCP misst, wann der größte sichtbare Inhaltsblock im Viewport gerendert wird – meistens das Hero-Bild oder der Hauptüberschriften-Block. Es ist die wichtigste „gefühlte Ladezeit“ aus User-Sicht.

Häufige LCP-Probleme

• Riesige unkomprimierte Hero-Bilder (4 MB JPG)
• Render-Blocking-CSS mit 200+ KB Tailwind oder Bootstrap
• Langsamer Server mit hoher TTFB (Time to First Byte) > 800 ms
• Web-Fonts ohne font-display: swap – blockieren das Rendering
• Lazy-Loading des LCP-Elements – paradoxerweise verzögert das den LCP

Lösungen für besseren LCP

• Bilder optimieren: WebP/AVIF statt JPG, korrekte Dimensionen, max. 200 KB für Hero-Bilder
• LCP-Element preloaden: <link rel="preload" as="image" href="/hero.webp">
• Critical CSS inline, Rest async laden
• Schnelles Hosting: EU-Server, HTTP/3, CDN für statische Assets
• Server-Side-Rendering oder Static Site Generation statt rein clientseitiges React/Vue
• font-display: swap in allen @font-face-Regeln
• Caching: Cache-Control-Header für statische Assets, Page-Caching für dynamische Seiten

INP: Interaction to Next Paint

INP hat im März 2024 den älteren FID ersetzt. Während FID nur die erste Interaktion gemessen hat, betrachtet INP die schlechteste aller Interaktionen während des Besuchs. Es misst die Zeit zwischen einer Nutzeraktion (Klick, Tap, Tastendruck) und dem nächsten visuellen Update – also wie reaktionsschnell sich die Seite anfühlt.

Häufige INP-Probleme

• Long Tasks im Main-Thread (> 50 ms blockierende Skripte)
• Schwere JavaScript-Frameworks ohne Code-Splitting
• 3rd-Party-Scripts (Tag Manager, Analytics, Chat-Widgets, Werbenetzwerke)
• Forced Reflows – wiederholtes Lesen und Schreiben von DOM-Layout-Eigenschaften
• Synchrone XHR/Fetch-Calls in Click-Handlern

Lösungen für besseren INP

• Long Tasks zerlegen: setTimeout, requestIdleCallback, scheduler.yield()
• Code-Splitting: nur den Code laden, der für die aktuelle Seite gebraucht wird
• 3rd-Party defer/async: Tag Manager mit defer, Chat-Widget per Klick statt automatisch laden
• Reflow-Batching: alle DOM-Reads zuerst, dann alle DOM-Writes – via requestAnimationFrame
• Web Workers für rechenintensive Aufgaben (z. B. Bildbearbeitung, Datenparsing)
• Optimistic UI: Klick sofort visuell bestätigen, asynchrone Aktion im Hintergrund

CLS: Cumulative Layout Shift

CLS misst visuelle Stabilität – wie sehr „springt“ das Layout während des Ladens? Jeder kennt das frustrierende Erlebnis: Du willst auf einen Button klicken, aber im selben Moment lädt ein Werbebanner darüber, du klickst versehentlich auf die Werbung. Das ist Layout-Shift.

Häufige CLS-Probleme

• Bilder ohne width/height – Browser kennt die Höhe erst beim Laden
• Web-Fonts ohne size-adjust – Schriftwechsel verschiebt Layout
• Async geladene Ad-Banner ohne reservierten Platz
• Cookie-Banner, die plötzlich erscheinen und Inhalt verschieben
• CSS-Animationen, die Layout-Eigenschaften animieren (height, width, top) statt transform/opacity
• FOUC (Flash of Unstyled Content) – CSS lädt zu spät

Lösungen für besseren CLS

• Bilder mit width & height: Browser reserviert Platz, kein Sprung
• Aspect-Ratio-Boxen für Videos und iframes mit CSS aspect-ratio
• Reservierte Container für 3rd-Party-Inhalte (Werbung, Embeds)
• Cookie-Banner als Overlay statt im Dokumentfluss
• font-display: optional oder size-adjust auf System-Fonts angeglichen
• CSS-Stylesheet blocking laden statt async (FOUC vermeiden)
• Animationen über transform und opacity, nicht über Layout-Eigenschaften

Wo misst man Core Web Vitals?

Wichtig zu verstehen: Es gibt zwei Arten von Daten – Lab-Data (synthetische Messung in einer kontrollierten Umgebung) und Field-Data (echte Nutzer-Daten aus dem Chrome User Experience Report). Google nutzt für Rankings die Field-Data.

• PageSpeed Insights (pagespeed.web.dev) – kombiniert Lab und Field
• Google Search Console – Bereich „Core Web Vitals“ mit Field-Data deiner echten Nutzer
• Chrome DevTools Lighthouse – Lab-Data, gut für Debugging
• CrUX-Dashboard – Field-Data direkt aus dem Chrome User Experience Report
• Web-Vitals-JavaScript-Library – Real-User-Monitoring auf deiner eigenen Site

Tipp: Lab-Data kann gut aussehen, während Field-Data schlecht ist – z. B. wenn deine echten Nutzer langsamere Geräte oder schlechtere Verbindungen haben als das Test-Setup. Verlass dich auf die Search Console.

Was Core Web Vitals 2026 wirklich bringen

Eine bessere Performance verbessert nicht nur dein Ranking – sie verbessert direkt deine Conversion-Rate. Studien zeigen: Jede Sekunde Ladezeit kostet rund 7 % Conversion. Bei einem Shop mit € 100.000 Jahresumsatz sind das € 7.000 weniger – pro Sekunde. Performance ist 2026 kein „Nice-to-have“ mehr, sondern eine direkte Umsatz-Stellschraube.

Fazit

Core Web Vitals sind keine Hexerei. Mit ein paar systematischen Schritten – optimierte Bilder, sauberes Caching, schlanke JavaScript-Bundles, reservierte Container für dynamische Inhalte – bringst du fast jede Website in den grünen Bereich. Wenn du weiter willst als die grundlegenden Maßnahmen, lohnt sich ein Performance-Audit, das die Engpässe deiner spezifischen Site identifiziert. Mehr dazu auf unserer Performance-Optimierung-Seite.