Core Web Vitals auf Produktseiten: LCP senken

Core Web Vitals auf Produktseiten: LCP senken, ohne Bilder zu opfern

Seit 2021 nutzt Google die Core Web Vitals als Ranking-Signal. 2026 hat ihr Gewicht weiter zugenommen, und Produktseiten sind ihr wichtigstes Einsatzfeld: hochauflösende Bilder, Slider, In-den-Warenkorb-Buttons, dynamische Reviews — alles, was die Performance verschlechtert.

So optimieren Sie die 3 Metriken, die zählen (LCP, CLS, INP), auf einer Produktseite, ohne visuelle Qualität oder UX zu verlieren.

Die 3 Core Web Vitals im Jahr 2026

LCP (Largest Contentful Paint) — die Zeit, bis das größte sichtbare Element (typischerweise das Hauptproduktbild) angezeigt wird. Ziel: <2,5 s.

CLS (Cumulative Layout Shift) — die visuelle Stabilität: Elemente dürfen beim Laden nicht springen. Ziel: <0,1.

INP (Interaction to Next Paint) — seit März 2024 ersetzt INP FID. Misst die Verzögerung zwischen einem Nutzerklick (In den Warenkorb, Öffnen eines Menüs) und der visuellen Reaktion. Ziel: <200 ms.

Eine Produktseite, die alle 3 Schwellenwerte im grünen Bereich erfüllt, hat einen Ranking-Vorteil gegenüber Seiten, die das nicht schaffen. Der Abstand kann bei einem umkämpften Keyword 3–5 Positionen ausmachen.

LCP beim Hero-Bild: die größte Baustelle

Auf 90 % der Produktseiten ist das LCP das Hero-Bild (das erste Produktbild). Sein Gewicht und seine Ladezeit bestimmen alles.

Bildformat

WebP: 25–35 % leichter als JPEG, 2026 überall unterstützt. Der Standard.
AVIF: 40–50 % leichter als JPEG, bessere Qualität. Seit 2022 von Chrome/Firefox/Safari unterstützt. Wenn möglich bevorzugen.
JPEG: nur als Fallback für sehr alte Browser (<1 % des Traffics im Jahr 2026).

Liefern Sie je nach Browser das passende Format über <picture> aus:

<picture>
  <source srcset="/product.avif" type="image/avif" />
  <source srcset="/product.webp" type="image/webp" />
  <img src="/product.jpg" alt="..." />
</picture>

Abmessungen und Pixeldichte

Ein Hero-Bild, das auf dem Bildschirm mit 600×600 Pixeln angezeigt wird, sollte nicht 4000×4000 Pixel groß sein. Liefern Sie das Bild in der richtigen Größe plus eine 2x-Version für Retina-Displays aus:

<img
  src="/product-600.webp"
  srcset="/product-600.webp 1x, /product-1200.webp 2x"
  width="600"
  height="600"
  alt="..."
/>

In Shopify übernimmt die Liquid-Syntax img_url: '600x600' das automatisch. In WooCommerce über WP Fastest Image Optimizer oder Smush.

Intelligentes Lazy-Loading

Das Hero-Bild (das erste sichtbare Bild) nicht lazy-loaden: Es muss sofort geladen werden. Fügen Sie fetchpriority="high" hinzu:

<img
  src="/product-hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="..."
/>

Den gesamten Rest lazy-loaden (sekundäre Bilder, Reviews mit Fotos, ähnliche Produkte am Seitenende):

<img
  src="/product-thumbnail.webp"
  loading="lazy"
  alt="..."
/>

CDN und Cache

Alle Produktbilder sollten über ein CDN laufen (Cloudflare, Fastly, Bunny). Typischer Gewinn beim LCP: 30–50 % in Europa, 50–70 % außerhalb Europas.

Shopify enthält ein eigenes CDN (Fastly). WooCommerce erfordert eine explizite Konfiguration.

CLS: Ursachen und Korrekturen

CLS auf Produktseiten kommt hauptsächlich von:

Bilder ohne Abmessungen

<!-- ❌ Ursache für CLS -->
<img src="/product.webp" alt="..." />

<!-- ✅ Reserviert den Platz -->
<img src="/product.webp" width="600" height="600" alt="..." />

Auch bei einem responsiven Bild (CSS überschreibt width/height) sollten Sie die HTML-Attribute angeben — sie dienen als Hinweis, um den Platz vor dem Laden zu reservieren.

Ein Banner wie „Kostenloser Versand ab 50 €“, das 500 ms nach dem Laden erscheint und den gesamten Inhalt nach unten schiebt, führt zu katastrophalem CLS.

Lösung: Reservieren Sie den Platz im initialen HTML mit min-height und füllen Sie den Inhalt erst danach.

Webfonts, die die Textgröße verändern

Wenn Sie eine benutzerdefinierte Schrift laden, kommt sie mit Verzögerung. In der Zwischenzeit wird der Text in einer Fallback-Schrift mit anderen Metriken angezeigt. Wenn die endgültige Schrift geladen ist, verschiebt sich alles.

Lösung: font-display: optional oder font-display: swap mit passendem size-adjust:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
  size-adjust: 100%; /* Match fallback metrics */
}

Karussell / Slider für Produktbilder

Slider sind eine häufige Ursache für CLS, wenn sie schlecht umgesetzt sind. Regeln:

Die Höhe des Slider-Containers festlegen (height: 600px zum Beispiel)
Keine JS-Paginierung, die beim Klick die Höhe verändert
Für Thumbnails sind die Abmessungen angegeben

INP: In den Warenkorb und andere kritische Interaktionen

INP misst die schlechteste Reaktionszeit auf Nutzerinteraktionen. Auf einer Produktseite sind die wichtigsten Interaktionen:

Klick auf „In den Warenkorb“
Wechsel der Variante (Größe, Farbe)
Öffnen eines Burger-Menüs
Scrollen in einem Karussell

Typische Ursachen für einen hohen INP:

Blockierendes JavaScript

Drittanbieter-Bibliotheken (Facebook Pixel, Google Tag Manager, Hotjar, Review-Widgets) sind die häufigsten Verursacher. Jedes Script, das auf dem Main Thread läuft, blockiert Interaktionen.

Lösungen:

Drittanbieter-Scripts nach Möglichkeit mit defer oder async laden
In einen Web Worker auslagern, wenn kritisch
Analytics-Pixel über ein einziges Tag konsolidieren (GTM)
Bewusste Verzögerung: Hotjar nicht vor 3 Sekunden nach dem First Contentful Paint laden

Schwere JavaScript-Handler beim Klick

Ein Klick auf „In den Warenkorb“, der 5 API-Aufrufe auslöst, 3 Elemente animiert und ein Modal öffnet, kann 500 ms bis zur Reaktion brauchen.

Optimierungen:

Optimistic UI: Zeigen Sie das Feedback sofort an (Button ändert seinen Zustand), auch wenn die API 300 ms für die Antwort braucht
Handler entprellen: Vermeiden Sie, Berechnungen bei jedem Hover neu zu starten
Animationen nach Möglichkeit in CSS statt in JS umsetzen

Hydration bei SPA / Frameworks

Wenn Sie React/Next/Vue verwenden, kann die anfängliche „Hydration“ den Main Thread 1–2 Sekunden blockieren. In dieser Zeit funktionieren Klicks nicht.

Lösungen:

Server-side rendering mit anfangs begrenztem interaktivem Inhalt
Progressive Hydration: zuerst die kritischen Teile hydratisieren
In Next.js 16+ "use client" sparsam einsetzen — je mehr Komponenten auf dem Server laufen, desto besser ist der INP

Tools zur Messung

Lab tools (simulierte Daten, nützlich in der Entwicklung):

PageSpeed Insights — schnell, öffentlich
Lighthouse (in Chrome DevTools integriert) — detailliert
WebPageTest — mehr Konfiguration, Tests auf mehreren Geräten

Field data (reale Nutzerdaten, für Google entscheidend):

Chrome User Experience Report (CrUX) — öffentliche aggregierte Daten
Google Search Console → Core Web Vitals — speziell für Ihre Website
PostHog, Vercel Analytics, Cloudflare Web Analytics — kontinuierliches Monitoring

Wichtige Regel: Nur field data zählt für das Ranking. Ein perfekter Lab-Score bei schlechten Field-Werten = kein positiver SEO-Effekt.

Nach Plattform

Shopify

Shopify liefert standardmäßig ordentliche Core Web Vitals. Die offiziellen Themes (Dawn, Studio, Crave) sind optimiert. Schlechte Core Web Vitals bei Shopify kommen fast immer von:

Third-party-Apps, die schweres JS einfügen
Schlecht optimierten Premium-Themes von Drittanbietern
Nicht komprimierten Bildern

Audit in Shopify: Entfernen Sie unnötige Apps (Online Store → Apps), verwenden Sie ein aktuelles offizielles Theme und komprimieren Sie die Bilder.

WooCommerce

Mehr Schwankungen je nach Hosting und Plugins. Empfohlener Stack:

Leistungsfähiger Hoster: Kinsta, WP Engine, Hostinger Cloud (kein günstiges Shared Hosting)
Leichtes Theme: offizielles Storefront oder ein optimiertes Custom-Theme (nicht Divi oder Avada)
Nur notwendige Plugins
Cache-Plugin: WP Rocket, Cache Enabler
Plugin zur Bildoptimierung: ShortPixel, Imagify

Headless

Mit Next.js und next/image erfolgt die Optimierung automatisch. Bei einem Custom-Frontend: manuell umsetzen (Formate, lazy, fetchpriority).

FAQ

Wie lange dauert es, bis Google Verbesserungen bei den Core Web Vitals berücksichtigt?

Für CrUX werden 28 Tage an „field data“ aggregiert. Nach dem Deployment von Optimierungen sollten Sie 4–6 Wochen einplanen, bis der Google-Score die Realität widerspiegelt. Bleiben Sie geduldig und rollen Sie nach 1 Woche nicht zurück.

Sind Core Web Vitals für das Ranking wichtiger als der Inhalt?

Nein. Der Inhalt (Relevanz, Qualität, Backlinks) bleibt der dominierende Faktor. Core Web Vitals sind ein Tie-Breaker: Bei zwei Seiten mit vergleichbarem Inhalt rankt die mit den besseren CWV höher. Den Inhalt zu verschlechtern, um bei den CWV zu gewinnen, ist kontraproduktiv.

Kann ich ohne CDN im grünen Bereich sein?

Für eine deutsche Website mit ausschließlich deutschem Publikum: ja — wenn Ihr Server in Deutschland steht und gut konfiguriert ist. Für internationales Geschäft ist ein CDN fast Pflicht. Das kostenlose Cloudflare reicht in 80 % der Fälle aus.

Muss ich Bildqualität opfern, um beim LCP zu gewinnen?

Nein. Mit der richtigen Konfiguration (WebP/AVIF + Abmessungen + CDN + fetchpriority) ist ein 600×600-Bild mit 40 KB in vergleichbarer Qualität zu einem JPEG mit 200 KB möglich. Seit 2023 ist dieser Verzicht nicht mehr nötig.

Sind die Core Web Vitals auf Mobile und Desktop gleich?

Die Schwellenwerte ja, aber die Scores werden von Google getrennt gemessen. Eine Seite kann auf Desktop „Good“ und auf Mobile „Poor“ sein (das kommt häufig vor). Google nutzt für das Ranking hauptsächlich die Mobile-Metriken (Mobile-First Indexing).

Wie viel Geld sollte ich in die CWV-Optimierung investieren?

Einordnung: Wenn Ihre Seiten bereits „Good“ sind, lohnt sich keine weitere Investition. Wenn Sie bei „Needs improvement“ liegen, reichen 1–3 Wochen Entwicklung für die wichtigsten Korrekturen (Bilder, Third-party-Scripts, CDN). Wenn Sie auf allen Seiten „Poor“ sind, ist möglicherweise ein technischer Relaunch nötig — beginnen Sie mit einem vollständigen Audit.

Ecomptimize optimiert die Core Web Vitals auf den Produktseiten Ihres Katalogs automatisch. Siehe Ecomptimize für Shopify oder Ecomptimize für WooCommerce.