Wir verwenden Cookies, um deine Erfahrung zu verbessern, den Datenverkehr zu analysieren und Inhalte zu personalisieren. Du kannst alle Cookies akzeptieren oder auswählen, welche Kategorien zugelassen werden. Mehr erfahren
Kern-Web-Vitalien für E-Commerce 2026: LCP, INP, CLS-Fehlerbehebungen | Ordiko
Leitfaden
Kern-Web-Vitalien für E-Commerce 2026: LCP, INP, CLS-Fehlerbehebungen
Praktischer Leitfaden 2026 zu Kern-Web-Vitalien im E-Commerce — LCP/INP/CLS-Schwellenwerte, Ursachen aus der Praxis und die Fehlerbehebungen, die den Unterschied auf PDP und PLP ausmachen.
PT1H
TL;DR. Die Core Web Vitals im Jahr 2026 sind LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1 bei p75. Auf E-Commerce-Seiten wird LCP durch das Vorladen des Hero-Bildes, INP durch das Verzögern von JS und die Verwendung der Concurrent-Funktionen von React 18+ sowie CLS durch das Reservieren von Platz für Bilder und dynamische Bereiche festgelegt. Google bewertet bei p75 über einen Zeitraum von 28 Tagen; Korrekturen benötigen Wochen, um sich auszuwirken.
2026 Schwellenwerte
Metrik
Gut
Verbesserungsbedarf
Schlecht
LCP
≤ 2,5s
2,5s – 4,0s
> 4,0s
INP
≤ 200ms
200ms – 500ms
> 500ms
CLS
≤ 0,1
0,1 – 0,25
> 0,25
TTFB
≤ 800ms
800ms – 1,8s
> 1,8s
Quelle: . INP ersetzte FID als Core Web Vital im März 2024 und bleibt die Metrik für 2026.
Häufige Fragen
Beeinflussen Kern-Web-Vitalien die Rankings?
Ja, seit 2021 — aber als Tiebreaker und nicht als primäres Signal. Zwei Seiten mit gleicher Inhaltsqualität werden in CWV-Reihenfolge eingestuft. Das Beheben von CWV auf einer schlecht eingestuften Seite wird sie nicht plötzlich höher einstufen, wenn der Inhalt schwach ist.
Warum ist INP schwieriger zu beheben als LCP?
LCP ist hauptsächlich ein CDN- und Bildoptimierungsproblem mit gut verstandenen Lösungen. INP ist ein JavaScript-Ausführungsproblem, das eine Analyse von Komponente zu Komponente erfordert. Jedes Interaktionsereignis kann einen anderen Engpass haben (Filterklick vs. Warenkorb hinzufügen vs. Variantenwechsel).
Was ist ein gutes INP-Ziel für PDP?
Unter 200 ms p75 ist 'gut'. Unter 100 ms ist auf modernen PDPs mit Disziplin (RSC, keine schweren Skripte von Drittanbietern, entprellte Eingaben) erreichbar. Über 500 ms ist 'schlecht' und wirkt sich wahrscheinlich auf die Rankings aus.
Wie geht Ordiko standardmäßig mit CWV um?
Ordiko liefert Next.js 16 Cache Components + PPR, das eine statische Hülle mit dem bereits vorab geladenen LCP-Bild und Suspense-Grenzen für dynamische Inhalte streamt. Standardmäßig liegt INP unter 200 ms auf typischen PDPs ohne maßgeschneiderte Optimierung.
Google verwendet CWV als Signal für die Seitenbenutzererfahrung im Ranking. Daten von echten Nutzern zeigen, dass Seiten mit durchweg grünen CWV vergleichbare Seiten mit schlechten CWV in wettbewerbsintensiven Nischen übertreffen.
Über die Rankings hinaus beeinflusst CWV direkt die Konversion. Studien aus 2024–2025 zeigen konsequent:
Verbesserung des LCP um 1 Sekunde: 5–15% Anstieg der Konversion auf PDP.
INP unter 200ms: 10–20% Reduzierung der Warenkorbabbrüche.
CLS unter 0,1: spürbare Verbesserung der UX-Qualitätswahrnehmung.
Richtig messen
Zwei Datenquellen sind wichtig:
CrUX (Chrome User Experience Report): Daten von echten Nutzern, die Google verwendet, um Sie zu bewerten. 28-tägiges rollierendes Fenster, p75. In PageSpeed Insights und der Search Console angezeigt.
Ihr eigenes RUM: Daten von echten Nutzern, die Sie über die web-vitals-Bibliothek oder Ihr CDN sammeln. Zeigt aktuellere Daten und ermöglicht das Filtern nach Seitentyp, Gerät, Land.
Synthetische Tools (Lighthouse, WebPageTest) sind nützlich für Diagnosen, aber nicht für die Bewertung.
LCP-Korrekturen (largest contentful paint)
Im E-Commerce ist LCP fast immer:
Das Hero-Bild auf der Startseite, PLP und PDP.
Die H1 + der erste Absatz auf Blog-/Artikel-Seiten.
Die großen Gewinne:
LCP-Bild vorladen mit <link rel="preload" as="image" fetchpriority="high">:
Reguläre Ausdrücke aus Ereignis-Handlern herausheben — das Neuerstellen von Regex in einem heißen Pfad kostet messbares INP.
Nicht kritische Drittanbieter-Skripte verzögern. Marketing-Pixel, Chat-Widgets, A/B-Test-SDKs: Laden Sie sie mit strategy="afterInteractive" oder lazyOnload.
CLS-Korrekturen (cumulative layout shift)
Die großen Gewinne:
Immer Breite/Höhe für Bilder festlegen. Browser reservieren den richtigen Platz.
Platz für eingebettete Inhalte reservieren. iframes, Anzeigen, Videoplayer benötigen explizite Dimensionen oder Container mit Seitenverhältnis.
Vermeiden Sie `font-display: swap` ohne Fallback-CSS für Schriftarten. Der Swap führt zu Neuanordnungen des Textes. Verwenden Sie size-adjust, um Metriken abzugleichen oder akzeptieren Sie font-display: optional.
Inhalte nicht über bestehenden Inhalten einfügen. Bannerbenachrichtigungen, Cookie-Zustimmungen, Verkaufsbanner — rendern Sie sie an einer Position, die die Seite nicht verschiebt.
Skeleton-Loader sollten den realen Inhaltsdimensionen entsprechen. Ein Skeleton, das kleiner ist als der geladene Inhalt, verschiebt die Seite.
Seiten-spezifische Hinweise
Startseite
Das Hero-Bild ist LCP. Laden Sie es vor.
Karussells sind CLS-Minen. Verwenden Sie nur CSS oder rendern Sie die erste Folie vor.
PLP (Produktliste / Kategorie)
LCP ist normalerweise das Bild der ersten Produktkarte.
INP sind Filterklicks und Seitenzahlen. Verwenden Sie startTransition aggressiv.
CLS ist das Neuanordnen des Produktgitters, wenn Filter angewendet werden. Reservieren Sie die Höhe des Gitters.
PDP
LCP ist das Hauptproduktbild.
INP ist der Variantenwechsel und das Hinzufügen zum Warenkorb. Optimistische UI ist Pflicht.
CLS sind die Miniaturansichten der Produktgalerie, die nach dem Hauptbild geladen werden.
Warenkorb / Checkout
INP ist hier entscheidend. Ein langsamer "Bestellung aufgeben"-Button kostet Bestellungen.
CLS durch das Laden von Zahlungs-iframes (Stripe Elements usw.). Platz reservieren.
Werkzeuge
Werkzeug
Wofür es gut ist
PageSpeed Insights
Diagnose einer einzelnen URL mit echtem Nutzer (CrUX) Overlay
Lighthouse
Synthetische Messung für Entwickler-Workflows
WebPageTest
Netzwerkgedrosselte, mehrstandortige Messung
Search Console → CWV
Domain-Level p75 über 28 Tage
Ihr eigenes RUM (web-vitals)
Echtzeit-Felddaten, aufgeteilt nach Seite, Gerät, Land
Edge-Rendering von statischen Shells (TTFB ≤ 100ms).
LCP-Bild standardmäßig auf PDP, PLP, Startseite vorgeladen.
Suspense-Grenzen um dynamische Inseln (Warenkorb, zuletzt angesehen, personalisiertes Hero).
startTransition + useOptimistic bei Filter- und Variantensteuerungen.
200ms debouncte Suche mit AbortController.
Typisches p75 von echten Nutzern auf einem Standard-Ordiko-PDP: LCP 1,0–1,8s, INP 80–160ms, CLS < 0,05.
FAQ
Beeinflussen Core Web Vitals die Rankings? Ja, seit 2021 — aber eher als Tiebreaker denn als primäres Signal. Zwei Seiten mit gleicher Inhaltsqualität werden in CWV-Reihenfolge eingestuft. Das Beheben von CWV auf einer schlecht eingestuften Seite wird sie nicht plötzlich hochstufen, wenn der Inhalt schwach ist.
Warum ist INP schwieriger zu beheben als LCP? LCP ist hauptsächlich ein Problem der CDN- und Bildoptimierung mit gut verstandenen Lösungen. INP ist ein Problem der JavaScript-Ausführung, das eine Analyse von Komponente zu Komponente erfordert. Jedes Interaktionsevent kann einen anderen Engpass haben (Filterklick vs. Warenkorb hinzufügen vs. Variantenwechsel).
Was ist ein gutes INP-Ziel für PDP? Unter 200ms p75 ist 'gut'. Unter 100ms ist auf modernen PDPs mit Disziplin erreichbar (RSC, keine schweren Drittanbieter-Skripte, debouncte Eingaben). Über 500ms ist 'schlecht' und wirkt sich wahrscheinlich auf die Rankings aus.
Wie geht Ordiko standardmäßig mit CWV um? Ordiko liefert Next.js 16 Cache Components + PPR, das eine statische Shell streamt, bei der das LCP-Bild bereits vorgeladen ist, und Suspense-Grenzen für dynamische Inhalte. Das Standard-INP liegt unter 200ms auf typischen PDPs ohne maßgeschneiderte Optimierung.