Fallstudie: Wie wir die Core Web Vitals in zwei Wochen um 60 % verbessert haben

## Der Ausgangszustand

Eine Next.js-E-Commerce-Website mit 12.000 SKUs und einem monatlichen Umsatz von 2 Mio. $. Ihr organischer Traffic war sechs Monate lang rückläufig. Die Google Search Console zeigte das Problem: 68 % der URLs lagen im „poor"-LCP-Bereich.

Danach: 92 % „good" über alle drei Metriken hinweg. Hier ist genau, was wir geändert haben.

LCP: 4,2 s → 1,1 s

Das Hero-Bild auf jeder Produktseite wurde in voller Auflösung geladen – 4000x4000 Pixel, 2,3 MB. Auf dem Papier stand „optimiert", aber sie nutzten ein generisches CDN ohne WebP-Konvertierung. Für eine vollständige Aufschlüsselung zur Diagnose und Behebung von LCP sieh dir unseren LCP-Deep-Dive-Leitfaden an.

Was wir gemacht haben:

- Alle Hero-Bilder mit einer Qualität von 85 % in WebP konvertiert

- fetchpriority="high" zum LCP-Bild hinzugefügt

- Responsive Bildgrößen über die Next.js-Image-Komponente mit dem sizes-Attribut implementiert

- Das Review-Widget von Drittanbietern unter den Fold verschoben (es lud 180 KB JavaScript vor dem Hero-Bild)

Der größte Gewinn war das Review-Widget. Das Entfernen eines einzigen <script>-Tags aus dem kritischen Pfad reduzierte den LCP um allein 1,8 Sekunden.

INP: 320 ms → 95 ms

Die Website hatte fünf Analytics-Skripte, die alle sofort (eager) geladen wurden. Session Replay, Heatmaps, zwei verschiedene Analytics-Anbieter und einen Chatbot.

Was wir gemacht haben:

- Auf einen einzigen Analytics-Anbieter konsolidiert

- Chatbot auf den Idle-Callback verschoben

- Heatmaps auf ein per Cookie-Zustimmung gesteuertes Lazy Loading umgestellt

- Event-Handler auf der Produktseite geprüft – eine Akkordeon-Komponente fügte bei jedem Rendern Listener neu an

Das Latenz-Messungstool zeigte, dass 75 % des INP von Skripten Dritter stammten. Drei davon zu entfernen war die gesamte Lösung.

CLS: 0,25 → 0,03

Das Layout verschob sich aus drei Gründen: fehlende width/height-Angaben bei Produktbildern, eine dynamisch eingefügte Banneranzeige und eine Web-Schriftart, die nach dem Paint wechselte.

Was wir gemacht haben:

- Explizites width und height zu allen Produktbildern hinzugefügt

- Einen 60-px-Platz für den Banner-Anzeigencontainer reserviert (auch wenn er leer ist)

- Die primäre Schriftart vorgeladen und font-display: optional verwendet

Der Zeitplan

Tag 1-3: Audit mit Lighthouse, WebPageTest und CrUX-Daten. Tag 4-8: Bildoptimierung und Skript-Konsolidierung. Tag 9-12: Layout-Fixes und Schriftarten-Optimierung. Tag 14: In der Search Console wurden bei allen drei Metriken 92 % „good" gemessen.

Das Ergebnis? Der organische Traffic erholte sich innerhalb von drei Wochen auf das vorherige Niveau, und die Conversion-Rate verbesserte sich um 12 % – schnellere Seiten konvertieren besser. Für eine vollständige Anleitung zur Behebung aller Core-Web-Vitals-Metriken sieh dir unseren Core-Web-Vitals-Leitfaden an.

Verwandte Artikel

- Core-Web-Vitals-Probleme beheben: LCP, INP und CLS erklärt

- LCP-Deep-Dive: Diagnose und Behebung der schwierigsten Core Web Vital