Was sind Core Web Vitals und warum sind sie plötzlich so wichtig?
Im Mai 2021 rollte Google das sogenannte Page Experience Update aus — eines der bedeutendsten Ranking-Updates der letzten Jahre. Zum ersten Mal flossen technische Nutzungserfahrungs-Metriken direkt in den Suchalgorithmus ein. Der Name für diese Metriken: Core Web Vitals. Drei Messwerte, die beschreiben, wie schnell, reaktiv und visuell stabil eine Website für echte Nutzer ist.
Was viele unterschätzen: Core Web Vitals sind keine akademische Übung. Google hat intern Milliarden von Nutzerdaten ausgewertet und festgestellt, dass Seiten mit schlechten Ladezeiten drastisch höhere Absprungraten haben. Wenn eine Seite länger als drei Sekunden zum Laden braucht, verlässt sie die Hälfte aller mobilen Nutzer. Diese Daten haben Core Web Vitals zu einem harten Ranking-Faktor gemacht — und 2025 ist ihre Bedeutung weiter gestiegen.
Seit März 2024 hat Google INP (Interaction to Next Paint) als offiziellen Core Web Vital eingeführt und damit FID (First Input Delay) abgelöst. Diese Änderung ist keine Kleinigkeit: FID maß nur die Verzögerung bis zur ersten Interaktion. INP misst hingegen die Reaktionsfähigkeit über alle Nutzerinteraktionen während des gesamten Seitenbesuchs — also jeden Klick, jede Texteingabe, jeden Tap. Das macht INP deutlich anspruchsvoller zu optimieren.
In 2025 ist die Situation eindeutig: Websites mit guten Core Web Vitals ranken besser, konvertieren mehr und haben niedrigere Bounce Rates. Es geht längst nicht mehr nur um SEO. Jede Sekunde langsamer Ladezeit kostet gemäß einer Amazon-Studie etwa 7% Conversion Rate. Für einen Online-Shop mit 100.000 € Monatsumsatz bedeutet das bei 2 Sekunden schlechterer Performance bis zu 14.000 € weniger Umsatz pro Monat — allein wegen technischer Trägheit.
Wichtig zu verstehen:Core Web Vitals sind kein einmaliges Projekt. Sie müssen kontinuierlich überwacht werden, weil sich jede neue Funktion, jedes Bild und jedes Script negativ auswirken kann.
Die drei Metriken erklärt
LCP — Largest Contentful Paint
LCP misst die Zeit, die vergeht, bis das größte sichtbare Element im Viewport vollständig geladen ist. Das ist meistens das Hero-Bild, ein großes Textblock oder ein Video-Poster. Der Name ist Programm: "Largest Contentful Paint" = wann ist der größte Inhalt gezeichnet?
Was LCP negativ beeinflusst: große, nicht optimierte Bilder (JPG ohne AVIF/WebP), langsame Server-Antwortzeiten (TTFB > 800ms), render-blockende CSS- und JavaScript-Ressourcen sowie fehlende Preload-Hinweise für kritische Assets. LCP ist der Messwert, bei dem die meisten Websites am meisten Potenzial haben.
INP — Interaction to Next Paint
INP misst, wie lange es dauert, bis der Browser auf eine Nutzerinteraktion (Klick, Tap, Tastatureingabe) visuell reagiert — und zwar nicht nur bei der ersten Interaktion, sondern über den gesamten Seitenbesuch hinweg. Der endgültige INP-Wert einer Seite entspricht dem 98. Perzentil aller gemessenen Interaktionen.
INP ist der schwierigste der drei Werte zu optimieren, weil er direkt mit JavaScript- Performance zusammenhängt. Typische Probleme: schweres JavaScript, das den Main Thread blockiert, lange Tasks über 50ms, aufgeblähte Event-Handler ohne Debouncing und synchrone DOM-Operationen. Single-Page-Applications haben hier oft die größten Probleme, weil sie extrem viel JavaScript auf dem Client ausführen.
CLS — Cumulative Layout Shift
CLS misst visuelle Instabilität — das frustrierende Phänomen, wenn du auf einen Button klicken willst und er plötzlich nach unten springt, weil ein Bild über ihm nachgeladen hat. Du kennst das: Du liest gerade einen Artikel, dann lädt ein Werbebanner ein und die ganze Seite verschiebt sich. Das ist CLS.
Häufige Ursachen: Bilder ohne width und height Attribute, dynamisch eingefügte Inhalte (Ads, Cookie-Banner), Webfonts die ohne font-display eingebunden sind und das Layout verschieben, sowie iFrames ohne definierte Dimensionen. Der gute News: CLS ist von den drei Metriken am einfachsten auf 0 zu bringen, wenn man die Ursachen kennt.
Wie du deine Core Web Vitals misst
Bevor du optimierst, musst du wissen, wo du stehst. Es gibt zwei grundlegend verschiedene Arten von Daten: Lab Data (synthetische Messungen in kontrollierten Bedingungen) und Field Data (echte Messungen von deinen echten Nutzern, gesammelt über das Chrome User Experience Report, kurz CrUX). Google verwendet für das Ranking ausschließlich Field Data — aber Lab Data ist unverzichtbar für die Diagnose.
1. Google PageSpeed Insights
Starte hier. pagespeed.web.dev zeigt dir sowohl Lab-Daten (Lighthouse-Score) als auch Field-Daten (CrUX) für Desktop und Mobil. Wichtig: Messe immer mobil zuerst — dort sind die Werte fast immer schlechter und dort hat Google den stärksten Ranking-Einfluss.
2. Google Search Console — Core Web Vitals Report
Die Search Console zeigt dir, wie viele deiner URLs als "Gut", "Verbesserungsbedarf" oder "Schlecht" eingestuft werden — basierend auf echten Nutzerdaten über die letzten 28 Tage. Das ist der Report, auf den Google schaut. Neue Seiten haben hier oft noch keine Daten, weil CrUX Mindest-Traffic benötigt.
3. Chrome DevTools → Performance Tab
Für tiefe Diagnose: Öffne DevTools, gehe auf "Performance", aktiviere "Web Vitals" und nimm eine Aufzeichnung auf. Du siehst genau, welcher Task den Main Thread blockiert, wo LCP stattfindet und welche Layout-Shifts ausgelöst werden. Drosselung auf "Slow 4G" simuliert mobile Bedingungen.
4. WebPageTest.org
Für professionelle Tiefenanalyse. WebPageTest kann von verschiedenen Standorten (Frankfurt, Wien, Zürich) mit verschiedenen Geräten und Verbindungen testen. Der Filmstrip-View zeigt visuell, wann LCP-Elemente erscheinen. Besonders wertvoll: der Waterfall-Chart zeigt blockierende Ressourcen auf einen Blick.
Lab vs. Field Data — der entscheidende Unterschied:Lighthouse kann "100/100" zeigen, während Google Search Console deine Seite als "Schlecht" einstuft. Das passiert, weil Lab Data unter optimalen Bedingungen misst. Field Data spiegelt echte Nutzer auf echten Geräten wider — oft auf älteren Smartphones mit schlechter Verbindung.
8 konkrete Maßnahmen um LCP zu verbessern
LCP ist der Messwert mit dem größten Impact. Eine schlechte LCP-Zeit ist fast immer das größte Performance-Problem — und sie lässt sich mit den folgenden Maßnahmen systematisch angehen.
1. Bilder in AVIF/WebP konvertieren
AVIF-Bilder sind durchschnittlich 50% kleiner als JPEG bei gleicher Qualität. In Next.js nutzt du die eingebaute Image-Komponente, die automatisch optimiert:
import Image from 'next/image'
// Next.js konvertiert automatisch in AVIF/WebP
<Image
src="/hero.jpg"
alt="Hero Bild"
width={1200}
height={630}
priority // fetchpriority="high" automatisch
sizes="100%"
/>2. fetchpriority="high" auf das LCP-Element setzen
Der Browser weiß standardmäßig nicht, welches Bild das LCP-Element ist. Mit fetchpriority="high" sagst du ihm explizit: dieses Bild ist kritisch, lade es zuerst.
<!-- Vanilla HTML -->
<img
src="/hero.avif"
alt="Hero"
width="1200"
height="630"
fetchpriority="high"
loading="eager"
/>3. Kritische Ressourcen preloaden
Wenn dein LCP-Element ein Hintergrundbild aus CSS ist oder ein Font, der für große Headlines nötig ist, muss der Browser es erst entdecken — dann laden. Mit Preload verkürzt du diesen Discovery-Prozess:
<link
rel="preload"
as="image"
href="/hero.avif"
type="image/avif"
/>
<!-- Für kritische Fonts -->
<link
rel="preload"
as="font"
href="/fonts/cormorant.woff2"
type="font/woff2"
crossorigin="anonymous"
/>4. Server-seitig rendern statt client-seitig
Client-seitiges Rendering (React ohne SSR) bedeutet: der Browser lädt erst JavaScript, führt es aus, baut dann das DOM auf. LCP kann nicht stattfinden, bevor das DOM steht. Next.js App Router rendert standardmäßig server-seitig — nutze das konsequent und vermeide unnötiges 'use client'.
5. CDN verwenden
Ein Content Delivery Network (CDN) wie Cloudflare, AWS CloudFront oder Vercel Edge Network cached deine Seiten in Rechenzentren weltweit. Ein Nutzer in Wien lädt deine Seite dann nicht mehr aus einem Server in Frankfurt, sondern aus Wien selbst. TTFB (Time to First Byte) sinkt oft von 800ms auf unter 100ms.
6. CSS Critical Path isolieren
Wenn der Browser eine HTML-Seite lädt, wird er für jedes <link rel="stylesheet"> im <head> blockiert — er wartet auf das CSS bevor er rendert. Lagere das CSS, das für den Above-Fold-Bereich nötig ist, in inline <style> Tags aus und lade den Rest asynchron.
7. font-display: swap
Ohne font-display: swap wartet der Browser mit dem Anzeigen von Text, bis die Webfont geladen ist. Das kann LCP um Sekunden verzögern. Mit swap zeigt er sofort einen Fallback-Font an und tauscht ihn dann gegen die Webfont aus.
8. Hosting-Performance optimieren
Shared Hosting auf günstigen Plänen hat oft TTFB-Werte von 2-3 Sekunden — und damit kann LCP grundsätzlich nicht gut sein. Wechsle auf VPS-Hosting, Platform-as-a-Service (Vercel, Netlify, Render) oder Managed WordPress-Hosting (Kinsta, WP Engine). Die Investition amortisiert sich durch bessere Rankings und mehr Conversions.
INP optimieren: Das unterschätzte Problem
INP ist der Messwert, der 2025 die meisten Überraschungen bereithält. Viele Entwickler haben ihre Seite auf gute LCP-Werte optimiert — und stellen dann fest, dass INP trotzdem im roten Bereich ist. Das liegt daran, dass INP ausschließlich JavaScript-Verhalten misst und viele moderne Websites schlicht zu viel JavaScript auf dem Main Thread ausführen.
Long Tasks aufbrechen (>50ms = Problem)
Jede Aufgabe auf dem Main Thread, die länger als 50ms dauert, gilt als "Long Task" und blockiert den Browser. Während ein Long Task läuft, kann keine Nutzerinteraktion verarbeitet werden. Teile große Operationen auf: statt alles synchron zu verarbeiten, nutze setTimeout(fn, 0) oder die neue scheduler.yield() API.
// Alte Weise: blockiert den Main Thread
function processAllItems(items) {
items.forEach(item => heavyOperation(item))
}
// Besser: Mit scheduler.yield() (2025 API)
async function processAllItems(items) {
for (const item of items) {
heavyOperation(item)
// Nach jeder Iteration: Browser kann Inputs verarbeiten
await scheduler.yield()
}
}Event-Handler debouncing
Scroll-Events, Resize-Events und Input-Events feuern sehr häufig — manchmal hunderte Male pro Sekunde. Wenn jeder Event-Handler teures DOM-Manipulation oder API-Calls auslöst, blockiert das den Main Thread massiv. Debouncing verzögert die Ausführung bis der Nutzer eine kurze Pause einlegt.
React Concurrent Mode und Suspense
React 18 mit Concurrent Features erlaubt es React, das Rendering zu unterbrechen und priorisieren. Nutze useTransition für nicht-dringende Updates und Suspense für asynchrones Datenladen. Das verhindert, dass teure Re-Renders die Interaktion blockieren.
Web Workers für Heavy Computation
Berechnungen, die nicht auf das DOM zugreifen müssen — Datentransformationen, Parsing, Kryptographie, Bildverarbeitung — können in einen Web Worker ausgelagert werden. Web Workers laufen in einem separaten Thread und blockieren den Main Thread nicht.
Faustregel für INP:Weniger JavaScript ist fast immer besser JavaScript. Überprüfe regelmäßig, welche NPM-Pakete du wirklich brauchst. Bibliotheken wie Lodash, Moment.js oder alte jQuery-Plugins können den INP-Wert erheblich verschlechtern.
CLS: Layoutverschiebungen eliminieren
Cumulative Layout Shift ist der einzige Core Web Vital, der sich auf 0 bringen lässt — und bei dem konsequente Disziplin in der Entwicklung 90% der Probleme verhindert. Die meisten CLS-Probleme entstehen durch einfache Fehler, die leicht zu beheben sind.
Immer width und height Attribute auf img-Tags
Ohne explizite Dimensionen weiß der Browser nicht, wie viel Platz er für ein Bild reservieren soll. Er reserviert gar keinen Platz — und wenn das Bild lädt, verschiebt sich alles darunter. Die Lösung ist simpel:
<!-- Ohne Dimensionen: CLS-Problem -->
<img src="/photo.jpg" alt="Foto" />
<!-- Mit Dimensionen: kein Layout Shift -->
<img
src="/photo.jpg"
alt="Foto"
width="800"
height="450"
style="max-width: 100%; height: auto;"
/>min-height für dynamische Bereiche
Bereiche, die dynamisch befüllt werden — Kommentar-Sektionen, Bewertungs-Widgets, API-Daten — sollten mit min-height versehen werden, damit der Browser von Anfang an Platz reserviert. Ein leerer Container mit min-height: 200px verhindert einen Layout Shift beim Laden des Inhalts.
font-display: optional für Zero-CLS Fonts
font-display: swap hilft gegen FOIT (Flash of Invisible Text), kann aber einen kleinen Layout Shift verursachen, wenn der Fallback-Font und die Webfont unterschiedliche Maße haben. font-display: optional verhindert das komplett, indem die Webfont nur dann verwendet wird, wenn sie bereits im Cache ist.
Skeleton Screens statt leerer States
Wenn Inhalte asynchron geladen werden, zeige Skeleton Screens — Platzhalter in der ungefähren Form des späteren Inhalts. Das verhindert Layout Shifts und verbessert die wahrgenommene Performance gleichzeitig.
Checkliste: Core Web Vitals Audit in 30 Minuten
Nutze diese Checkliste für einen schnellen ersten Audit deiner Website. Du brauchst dafür nur einen Desktop-Browser mit Chrome und ca. 30 Minuten Zeit.
Fazit
Core Web Vitals sind 2025 kein "nice to have" mehr. Sie sind gleichzeitig Ranking-Faktor und Umsatzfaktor. Jede Sekunde langsamerer Ladezeit kostet ~7% Conversion Rate — und schlechtere Rankings bedeuten weniger Traffic. Die gute Nachricht: Die meisten Probleme sind gut diagnostizierbar und mit den richtigen Maßnahmen zu beheben.
Starte mit PageSpeed Insights, identifiziere deine größten Baustellen und priorisiere LCP zuerst — dort liegt das meiste Potenzial. INP und CLS folgen. Messe regelmäßig, vor allem nach größeren Deployments. Und denke daran: Google sieht immer die Field Data — das Erlebnis deiner echten Nutzer auf echten Geräten. Das ist der Maßstab, an dem du dich messen lassen musst.
PixelCraft Media
Webdesign Agentur
Wir bauen Websites, die Besucher in Kunden verwandeln — mit Handwerk bis ins letzte Pixel.
Website kostenlos analysieren →