INP hat FID am 12. März 2024 als Core Web Vital abgelöst. 2026 gelten weiterhin LCP, INP und CLS. INP betrachtet die Reaktionsfähigkeit über den Besuch hinweg, nicht nur die Verzögerung vor der ersten Interaktion. Das verändert, welche Probleme du bei der Optimierung untersuchen solltest.
Google bewertet gute Feldwerte am 75. Perzentil, getrennt nach Mobilgeräten und Desktop: LCP höchstens 2,5 Sekunden, INP höchstens 200 Millisekunden und CLS höchstens 0,1. Ein Lighthouse-Labortest ist dafür kein Ersatz. Gute Werte helfen der Nutzererfahrung; bessere Rankings, Anfragen oder Verkäufe sind damit nicht garantiert.
LCP (Largest Contentful Paint): Die wahrgenommene Ladezeit#
LCP misst, wie lange es dauert, bis das größte sichtbare Element im Viewport vollständig gerendert ist. Typischerweise ist das ein Hero-Bild, ein Video-Poster oder ein großer Textblock. Google erwartet einen LCP-Wert unter 2,5 Sekunden.
Häufigste LCP-Probleme#
- Unkomprimierte Bilder: Ein Hero-Bild mit 2,4 MB statt 180 KB als WebP
- Render-blockierendes CSS/JS: Stylesheets und Scripts, die das Rendering verzögern
- Langsame Server-Antwortzeiten (TTFB): Datenbankabfragen, die 800ms+ dauern
- Fehlende Preload-Hinweise: Der Browser entdeckt das LCP-Element zu spät
Optimierungsstrategie#
Bildoptimierung:
- WebP oder AVIF als Standard-Format (30-50% kleiner als JPEG)
- Responsive
srcsetmit definierten Breakpoints: 640w, 768w, 1024w, 1280w, 1920w loading="eager"undfetchpriority="high"für das LCP-Element<link rel="preload" as="image">im Head für das Hero-Bild
Server-seitig:
- Static Generation (SSG) wo möglich. Vorgerendertes HTML kann die Serverarbeit pro Anfrage reduzieren
- CDN-Caching mit stale-while-revalidate Headers
- Edge Functions für personalisierte Inhalte ohne Backend-Roundtrip
- TTFB unter 200ms als Zielwert
INP (Interaction to Next Paint): Die neue Königsmetrik#
INP misst die Reaktionszeit einer Seite über alle Nutzerinteraktionen hinweg. Klicks, Taps, Tastatureingaben. Anders als FID, das nur die erste Interaktion bewertet hat, erfasst INP eine der langsamsten Interaktionen während des gesamten Seitenbesuchs. Google erwartet einen INP-Wert höchstens 200 Millisekunden.
Bei vielen Interaktionen ignoriert INP einzelne Ausreißer: pro 50 Interaktionen wird die langsamste ausgenommen. Scrollen und Hover zählen nicht als INP-Interaktion, können aber den Hauptthread belasten.
Warum INP anspruchsvoller ist als FID#
FID war vergleichsweise leicht zu optimieren, weil nur der erste Klick zählte. INP ist strenger: Wenn ein Nutzer nach 30 Sekunden auf einen Button klickt und der Main Thread durch ein schweres JavaScript-Bundle blockiert ist, verschlechtert das den INP-Score der gesamten Seite.
Optimierungsstrategie#
JavaScript-Optimierung:
- Code Splitting: Nur den JavaScript-Code laden, der für die aktuelle Seite benötigt wird. Bei Next.js passiert das automatisch pro Route
- Dynamic Imports: Schwere Bibliotheken (Kartenansichten, Diagramme, Editoren) erst bei Bedarf laden
- Web Workers: Rechenintensive Aufgaben vom Main Thread auslagern
- Debouncing und Throttling: Scroll- und Resize-Handler begrenzen
Rendering-Optimierung:
content-visibility: autofür Off-Screen-Bereiche- CSS Containment (
contain: layout style paint) für isolierte Komponenten - Virtualisierung für lange Listen (react-window, @tanstack/virtual)
requestAnimationFramestattsetTimeoutfür visuelle Updates
Third-Party Scripts:
- Analytics und Tracking asynchron laden oder verzögern
- Consent-Management-Plattformen auf Performance prüfen (manche blockieren den Main Thread 300ms+)
- Tag Manager schlank halten. Zusätzliche Tags können die Reaktionszeit belasten
CLS (Cumulative Layout Shift): Visuelle Stabilität#
CLS misst, wie stark sich sichtbare Elemente während des Ladens verschieben. Nichts frustriert Nutzer mehr als ein Button, der im letzten Moment wegspringt. Google erwartet einen CLS-Wert unter 0,1.
Häufigste CLS-Verursacher#
- Bilder ohne Dimensionen: Der Browser reserviert keinen Platz, bis das Bild geladen ist
- Dynamisch eingefügte Werbebanner: Schieben den Content nach unten
- Web Fonts: Schriftartwechsel (FOUT/FOIT) verschiebt Textblöcke
- Dynamische Inhalte: Cookie-Banner, Chat-Widgets, Notification-Bars
Optimierungsstrategie#
Layout-Reservierung:
widthundheightAttribute auf allen<img>und<video>Elementenaspect-ratioin CSS als Fallback- Skeleton Screens für dynamische Inhalte (Platzhalter in der exakten Größe des finalen Elements)
Font-Loading:
font-display: optional: Der Browser entscheidet abhängig von Timing und Verbindung, ob die Webfont angezeigt wird. Prüfe die Fallback-Schrift und mögliche Layout-Verschiebungen.- Font-Dateien als
<link rel="preload">vorladen - Subset-Fonts verwenden (nur benötigte Zeichen einbetten)
- Variable Fonts statt mehrerer Font-Dateien
Dynamische Elemente:
- Cookie-Consent-Banner mit
position: fixedstatt Flow-Layout - Ads mit reserviertem min-height
- Chat-Widgets als Overlay, nicht als Teil des Dokument-Flows
Verbesserungen nachvollziehbar messen#
Notiere für jede Messung URL, Datum, Gerät, Verbindung und Werkzeug. Vergleiche Feldwerte nur über passende Zeitfenster. Ein gewöhnlicher Lighthouse-Ladetest liefert keinen INP eines vollständigen Besuchs; dafür brauchst du reale Interaktionen, Feldwerte aus CrUX oder eigenes RUM. Dokumentiere Änderungen einzeln, soweit das möglich ist. Ein besserer Score allein belegt keinen Umsatz- oder Rankingeffekt.
SSR vs. Static Generation: Die richtige Rendering-Strategie#
Die Wahl der Rendering-Strategie hat massiven Einfluss auf die Core Web Vitals:
- Static Site Generation (SSG): Seiten werden zur Build-Zeit generiert. Das kann die Auslieferung beschleunigen; LCP hängt auch von Bildern, CSS, Netzwerk und Gerät ab. Ideal für Landingpages, Blog-Artikel, Produktkataloge
- Server-Side Rendering (SSR): Seiten werden pro Request generiert. Flexibler, aber langsamerer TTFB. Nötig für personalisierte oder hochdynamische Inhalte
- Incremental Static Regeneration (ISR): Kombination aus beiden. Statische Seiten, die sich im Hintergrund aktualisieren. Bester Kompromiss für die meisten Websites
Empfehlung: Nutzen Sie SSG als Default und SSR nur dort, wo es wirklich nötig ist. Jede Seite, die als statisches HTML ausgeliefert werden kann, kann Server-Arbeit sparen; miss die tatsächliche Wirkung auf LCP.
CDN-Konfiguration: Die letzte Meile optimieren#
Ein falsch konfiguriertes CDN kann alle Optimierungen zunichtemachen. Folgende Einstellungen sind kritisch:
- Cache-Control Headers:
public, max-age=31536000, immutablefür statische Assets - Stale-While-Revalidate: Zeigt gecachte Version, während im Hintergrund aktualisiert wird
- Brotli-Kompression: 15-20% kleiner als Gzip, von allen modernen Browsern unterstützt
- HTTP/3: Reduziert Latenz durch QUIC-Protokoll
- Edge Computing: Rechenintensive Aufgaben näher am Nutzer ausführen
Fazit: Performance ist kein Projekt, sondern ein Prozess#
Core Web Vitals-Optimierung ist keine einmalige Aufgabe. Jedes neue Feature, jedes Plugin, jede Drittanbieter-Integration kann die Scores verschlechtern. Bauen Sie Performance-Monitoring in Ihren Entwicklungsprozess ein:
- Lighthouse CI in der Build-Pipeline (blockiert Deployments bei Score-Verschlechterung)
- Real User Monitoring (RUM) mit eigenen Nutzerinteraktionen; CrUX als ergänzende aggregierte Feldquelle
- Wöchentliche Performance-Reviews im Team
Miss regelmäßig, welche Änderung deinen Besuchern wirklich hilft. Vergleiche zusätzlich Anfragen und Abschlüsse, statt einen besseren Laborwert automatisch als Geschäftserfolg zu werten.
