Core Web Vitals für E-Commerce: Warum Besucher mit hoher Kaufabsicht die schlechteste Performance erhalten

Das unsichtbare Performance-Problem im E-Commerce

Vielen meiner Kunden ist das Bestehen der Core Web Vitals sehr wichtig. Bestehen bedeutet, dass 75 % des gesamten Traffics eine gute user experience haben sollten. Ein bewundernswertes Ziel. Aber bei der Optimierung für diese 75 % wird eine kleine, aber entscheidende Gruppe von etwa 5 % übersehen: die Besucher, die zu Kunden konvertieren werden.

Die Ironie daran? Diese Besucher mit hoher Kaufabsicht erhalten oft die schlechteste Performance auf Ihrer Website. Nicht, weil Sie vergessen haben zu optimieren. Sondern weil Ihr Caching-System sie aktiv ausschließt.

Zuletzt überprüft von Arjen Karel im März 2026

Warum Ihre CrUX-Daten das Problem verbergen

Die Optimierung der Core Web Vitals konzentriert sich, meist aufgrund des Google-Ranking-Bonus, eher auf die Optimierung für den leicht unterdurchschnittlichen Besucher. Im E-Commerce ist es äußerst sinnvoll, darüber hinauszugehen und einen zusätzlichen Fokus auf Besucher mit hoher Kaufabsicht zu legen. Das sind die Besucher, die zu Kunden konvertieren.

Laut einer Untersuchung von Deloitte und Google führt eine Verbesserung der Ladegeschwindigkeit um 0,1 Sekunden zu einem Anstieg der "In den Warenkorb"-Aktionen bei Einzelhandels-Websites um 9,1 %. Das ist auch genau der Moment, in dem das Caching für sie nicht mehr funktioniert.

Wir können diese Nutzer typischerweise an der Anzahl der Artikel in ihrem Warenkorb identifizieren.

Es gibt noch einen weiteren blinden Fleck. CrUX (der Chrome User Experience Report) erfasst nur Chrome-Nutzer, die die Synchronisierung aktiviert haben. Viele E-Commerce-Käufer nutzen Safari auf mobilen Geräten oder Browser ohne Synchronisierung. Ihr CrUX-Dashboard zeigt möglicherweise grüne Werte an, während Ihre tatsächlichen Käufer etwas ganz anderes erleben. Deshalb erzählt ein bestandener CrUX-Score nicht die ganze Geschichte.

Die Caching-Klippe: Was passiert, wenn ein Nutzer etwas in den Warenkorb legt

Hier ist das Problem: Das Hinzufügen von Artikeln zu einem Warenkorb zerstört Ihr Caching. Und Caching ist das, was Ihre Website schnell macht.

Caching-Plugins deaktivieren das Full-Page-Caching für Nutzer mit dynamischen Inhalten. Etwas so Simples wie "Artikel in einem Warenkorb" zwingt den Server, die gesamte Seite bei jeder Anfrage neu zu generieren. Dies erhöht Ihre Time to First Byte erheblich, was sich direkt verlangsamend auf den Largest Contentful Paint und den First Contentful Paint auswirkt.

Die Zahlen sind dramatisch. Auf einer typischen WooCommerce-Website steigt die TTFB von etwa 100ms (gecached) auf 1.600ms oder mehr (ungecached). Das ist eine 16-fache Erhöhung der Serverantwortzeit in dem Moment, in dem jemand ein Produkt in seinen Warenkorb legt. Ich habe Fälle gesehen, in denen eingeloggte WooCommerce-Nutzer 5 bis 9 Sekunden auf eine Seite warten, die für anonyme Besucher in unter einer Sekunde lädt.

Wie die einzelnen Plattformen damit umgehen

WooCommerce setzt mehrere Cookies, wenn ein Nutzer etwas in den Warenkorb legt: woocommerce_cart_hash, woocommerce_items_in_cart und wp_woocommerce_session. In dem Moment, in dem ein Caching-Plugin (WP Rocket, LiteSpeed Cache, WP Super Cache) diese Cookies erkennt, umgeht es den Cache für jede Seite. Nicht nur für die Warenkorb-Seite. Ihre Startseite, Ihre Produktseiten, Ihre Kategorieseiten: alle ungecached. Darüber hinaus feuert WooCommerce bei jedem Seitenaufruf einen AJAX-Request an /?wc-ajax=get_refreshed_fragments, um das Mini-Warenkorb-Widget aktuell zu halten. Allein dieser Request kann auf Shared Hosting 2 bis 3 Sekunden dauern.

Dies ist ein Grund, warum WooCommerce die niedrigste Erfolgsquote bei den Core Web Vitals aller großen E-Commerce-Plattformen aufweist. Laut dem Web Almanac 2025 bestehen nur 33 % der WooCommerce-Websites alle drei Core Web Vitals auf dem Desktop, verglichen mit 76 % bei Shopify.

Shopify geht damit dank seiner verwalteten CDN-Infrastruktur besser um, aber selbst Shopify kann Seiten, die customer- oder cart-Objekte enthalten, nicht cachen. Der Unterschied besteht darin, dass die Basis-TTFB von Shopify (etwa 0,51 Sekunden) bereits schnell genug ist, sodass die Strafe für fehlendes Caching geringer ausfällt.

Magento 2 hat eine clevere Lösung gefunden: Die gesamte Seite wird immer gecached, auch für Warenkorb-Nutzer. Dynamischer Inhalt (Mini-Warenkorb, Nutzerbegrüßung, Lagerbestand) wird clientseitig per AJAX über /customer/section/load/ abgerufen und im localStorage des Browsers gespeichert. Die Seite selbst bleibt im Full-Page-Cache. Dies ist das Problem "slow by design", das auf Architekturebene gelöst wurde.

Ihre besten Kunden erhalten Ihre schlechtesten Seiten

Die Zahlen machen dies schmerzlich deutlich. Farfetch maß einen Rückgang der Conversion-Rate um 1,3 % für jede Erhöhung des LCP um 100ms. Blue Triangle fand heraus, dass die Conversion-Rate um 40 bis 50 % sinkt, wenn der LCP von 2 Sekunden auf 4 bis 5 Sekunden ansteigt.

Ein Besucher surft auf Ihrer schnellen, gecachten Website. Er findet ein Produkt, das ihm gefällt. Er klickt auf "In den Warenkorb". In genau diesem Moment stoppt das Caching und seine TTFB springt von 100ms auf 1.600ms. Von nun an ist jede Seite, die er besucht (Produkte vergleichen, Versandkosten prüfen, zum Checkout gehen), ungecached. Die Personen, die am ehesten kaufen werden, surfen nun auf der langsamsten Version Ihrer Website.

Auf Websites, die von CoreDash überwacht werden, sehen wir, dass Warenkorb-Nutzer auf selbstgehosteten E-Commerce-Plattformen eine 3- bis 5-mal schlechtere TTFB erleben als anonyme Besucher. Auf verwalteten Plattformen wie Shopify ist die Lücke kleiner (1,5- bis 2-fach), aber immer noch messbar.

So erkennen Sie dies in Ihren RUM-Daten

Sie können dieses Problem in Lighthouse oder PageSpeed Insights nicht sehen. Diese Tools testen als anonyme Besucher ohne Cookies. Ihre Laborwerte werden großartig aussehen, während Ihre tatsächlichen Käufer zu kämpfen haben.

Um dieses Problem zu finden, benötigen Sie Real User Monitoring. Segmentieren Sie Ihre RUM-Daten danach, ob der Nutzer ein Warenkorb-Cookie gesetzt hat. Vergleichen Sie TTFB, FCP und LCP zwischen diesen beiden Segmenten. Wenn Sie eine 2-fache oder größere Lücke sehen, ist die Umgehung des Caches Ihr Problem.

In den meisten Analytics-Plattformen können Sie auch nach Seitentyp segmentieren. Vergleichen Sie Ihre Produktübersichtsseiten (in der Regel gecached) mit Ihren Warenkorb- und Checkout-Seiten (nie gecached). Ein TTFB-Unterschied von mehr als 500ms zwischen diesen Seitentypen ist ein Alarmzeichen, dass Ihre Server-Wartezeit Aufmerksamkeit erfordert.

So beheben Sie die Performance für Besucher mit hoher Kaufabsicht

Beheben Sie das Backend, bevor Sie sich auf Caching verlassen. Verlassen Sie sich nicht ausschließlich auf Caching-Plugins. Analysieren Sie Ihren Backend-Code, optimieren Sie Datenbankabfragen und stimmen Sie Ihren Server fein ab, um eine schnelle TTFB auch ohne Caching sicherzustellen. Eine Website, die ohne Cache langsam ist, wird für Warenkorb-Nutzer katastrophal langsam sein. Der Cache-Dauer-Teilbereich der TTFB sollte nicht die ganze Schwerstarbeit leisten.

Verwenden Sie partielles Caching (Fragment-Caching). Cachen Sie die rechenintensiven Teile Ihrer Seite separat. Produktbeschreibungen, Navigationsmenüs und Footer-Inhalte ändern sich selten und können in Memcached oder Redis gecached werden, selbst wenn das Full-Page-Caching deaktiviert ist. Wenn ein Warenkorb-Nutzer eine Seite anfordert, setzt Ihr CMS diese aus gecachten Fragmenten zusammen, anstatt alles von Grund auf neu zu generieren. Dies kann die ungecachte TTFB um 60 bis 80 % reduzieren.

Rendern Sie dynamische Komponenten clientseitig. Das ist der Ansatz von Magento 2, und er funktioniert. Liefern Sie den Großteil der Seite als gecachtes HTML aus (serverseitig gerendert). Verwenden Sie dann JavaScript und einen kleinen API-Aufruf, um die dynamischen Teile (Warenkorb-Anzahl, Nutzerbegrüßung, personalisierte Empfehlungen) abzurufen, nachdem die Seite geladen wurde. Der Browser erhält das schnelle, gecachte HTML sofort. Die dynamischen Teile werden einen Moment später eingefüllt. Ihr LCP und FCP bleiben schnell, da sie von der gecachten Hülle und nicht vom dynamischen Inhalt gesteuert werden.

Shopifys Headless-Framework (Hydrogen) macht genau das: Produktdaten werden aggressiv mit langen TTLs gecached, während Warenkorb- und Kundendaten CacheNone() verwenden und nach dem Laden clientseitig abgerufen werden. Dieses Muster vermeidet auch INP-Probleme, da der dynamische Abruf asynchron erfolgt, anstatt die Benutzerinteraktion zu blockieren.

Implementieren Sie ein effektives Cache-Key-Management. Verwenden Sie einfache Schlüssel für statische Elemente (die URL reicht oft als Cache-Key aus) und komplexe Schlüssel für dynamische Inhalte, die die Nutzer-ID, Produkt-IDs und Zeitstempel enthalten. Dies ermöglicht es Ihnen, auf Nutzerebene zu cachen, anstatt zwischen "vollständig gecached" und "überhaupt nicht gecached" wählen zu müssen.

Deaktivieren Sie Warenkorb-Fragmente auf Nicht-Warenkorb-Seiten. Wenn Sie WooCommerce betreiben, deaktivieren Sie den Aufruf wc-ajax=get_refreshed_fragments auf Seiten, die keinen Mini-Warenkorb anzeigen. Mehrere Performance-Plugins (Perfmatters, FlyingPress) bieten dafür einen Schalter an. Dies eliminiert einen 2 bis 3 Sekunden dauernden AJAX-Aufruf bei jedem Seitenaufruf für Warenkorb-Nutzer.

Erwägen Sie Edge-Side Composition. Wenn Sie Cloudflare verwenden, können Workers Seiten an der Edge zusammenstellen: Liefern Sie den gecachten Seitenkörper aus dem CDN aus und injizieren Sie dynamische Fragmente (Warenkorb, Nutzerinfos) über separate Sub-Requests. Cloudflare hat eine Edge Side Includes-Implementierung für Workers veröffentlicht, die genau dies tut und Ihre TTFB schnell hält, während weiterhin personalisierte Inhalte ausgeliefert werden.