**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: [web.dev/vitals](https://web.dev/articles/vitals). INP ersetzte FID als Core Web Vital im März 2024 und bleibt die Metrik für 2026.
## Warum CWV wichtig ist
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:
1. **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.
2. **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:
1. **LCP-Bild vorladen** mit ``:
```html
```
2. **Verwenden Sie Next.js `` mit `priority`** für das LCP-Bild:
```tsx
```
3. **Moderne Formate bereitstellen**. AVIF schlägt WebP, WebP schlägt JPEG. Next.js Image erledigt dies automatisch.
4. **LCP-Bild nicht lazy-loaden**. `loading="lazy"` ist nur für Bilder unterhalb der Sichtfläche.
5. **Kritisches CSS für obenliegende Stile inline einfügen**. Vermeiden Sie das Blockieren von Stylesheet-Ladungen auf dem kritischen Renderpfad.
6. **Edge-Rendering verwenden**. TTFB von ≤ 100ms aus dem Edge-Cache sichert Ihnen den Großteil des LCP-Budgets.
## INP-Korrekturen (interaction to next paint)
INP misst den schlimmsten Fall unter allen Interaktionen auf einer Seite. Ein langsamer Filterklick kann Ihr INP für eine ganze Sitzung ruinieren.
Die großen Gewinne:
1. **Reduzieren Sie clientseitiges JS**. Verwenden Sie React Server Components, wo immer möglich. Jeder Kilobyte clientseitiges JS schadet INP.
2. **Verwenden Sie `startTransition` für nicht dringende Statusaktualisierungen**:
```tsx
import { startTransition, useState } from 'react';
function FilterButton({ filter }) {
const [isPending, startTransition] = useTransition();
return (
);
}
```
3. **Verwenden Sie `useOptimistic` für sofortiges Feedback**:
```tsx
import { useOptimistic } from 'react';
function Cart() {
const [cart, addOptimistic] = useOptimistic(serverCart);
return (
);
}
```
4. **Debounce-Eingaben**. Die Suchautovervollständigung sollte bei 150–250ms mit `AbortController` debounct werden, um laufende Anfragen abzubrechen:
```tsx
useEffect(() => {
const controller = new AbortController();
const timeout = setTimeout(() => {
fetch(`/api/search?q=${query}`, { signal: controller.signal });
}, 200);
return () => {
clearTimeout(timeout);
controller.abort();
};
}, [query]);
```
5. **Reguläre Ausdrücke aus Ereignis-Handlern herausheben** — das Neuerstellen von Regex in einem heißen Pfad kostet messbares INP.
6. **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:
1. **Immer Breite/Höhe für Bilder festlegen**. Browser reservieren den richtigen Platz.
```html
```
2. **Platz für eingebettete Inhalte reservieren**. iframes, Anzeigen, Videoplayer benötigen explizite Dimensionen oder Container mit Seitenverhältnis.
3. **Vermeiden Sie `font-display: swap` ohne Fallback-CSS für Schriftarten**. Der Swap führt zu Neuanordnungen des Textes. Verwenden Sie [size-adjust](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust), um Metriken abzugleichen oder akzeptieren Sie `font-display: optional`.
4. **Inhalte nicht über bestehenden Inhalten einfügen**. Bannerbenachrichtigungen, Cookie-Zustimmungen, Verkaufsbanner — rendern Sie sie an einer Position, die die Seite nicht verschiebt.
5. **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 |
## Wie Ordiko CWV standardmäßig behandelt
Der Technologie-Stack von Ordiko:
- Next.js 16 + React Compiler.
- `cacheComponents: true` + `experimental.ppr: "incremental"`.
- 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.
```
2. **Platz für eingebettete Inhalte reservieren**. iframes, Anzeigen, Videoplayer benötigen explizite Dimensionen oder Container mit Seitenverhältnis.
3. **Vermeiden Sie `font-display: swap` ohne Fallback-CSS für Schriftarten**. Der Swap führt zu Neuanordnungen des Textes. Verwenden Sie [size-adjust](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/size-adjust), um Metriken abzugleichen oder akzeptieren Sie `font-display: optional`.
4. **Inhalte nicht über bestehenden Inhalten einfügen**. Bannerbenachrichtigungen, Cookie-Zustimmungen, Verkaufsbanner — rendern Sie sie an einer Position, die die Seite nicht verschiebt.
5. **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 |
## Wie Ordiko CWV standardmäßig behandelt
Der Technologie-Stack von Ordiko:
- Next.js 16 + React Compiler.
- `cacheComponents: true` + `experimental.ppr: "incremental"`.
- 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.