Core Web Vitals im E-Commerce: Warum kaufbereite Besucher die schlechteste Performance erleben

Das unsichtbare Performance-Problem im E-Commerce

Viele meiner Kunden wollen die Core Web Vitals unbedingt bestehen. Bestehen heißt: 75 % des gesamten Traffic müssen eine gute Nutzererfahrung haben. Ein lobenswertes Ziel. Doch wer nur für diese 75 % optimiert, übersieht eine kleine, aber entscheidende Gruppe von rund 5 %: die Besucher, die zu Kunden werden.

Die Ironie dabei? Ausgerechnet diese kaufbereiten Besucher erleben oft die schlechteste Performance auf deiner Website. Nicht, weil du vergessen hast zu optimieren. Sondern weil dein Caching-System sie aktiv ausschließt.

Warum deine CrUX-Daten das Problem verschleiern

Bei der Optimierung der Core Web Vitals geht es – vor allem wegen des Google-Ranking-Bonus – meist darum, für den leicht unterdurchschnittlichen Besucher zu optimieren. Im E-Commerce ist es sinnvoll, darüber hinauszugehen und kaufbereite Besucher gezielt in den Fokus zu nehmen. Genau das sind die Besucher, die zu Kunden werden.

Laut einer Studie von Deloitte und Google führt eine Verbesserung der Ladezeit um 0,1 Sekunden bei Online-Shops zu 9,1 % mehr Warenkorb-Aktionen. Und genau das ist der Moment, in dem Caching für sie nicht mehr funktioniert.

Typischerweise erkennen wir diese Nutzer an der Anzahl der Artikel in ihrem Warenkorb.

Es gibt noch einen weiteren blinden Fleck: CrUX (der Chrome User Experience Report) erfasst nur Chrome-Nutzer mit aktivierter Synchronisierung. Viele E-Commerce-Käufer nutzen Safari auf dem Smartphone oder Browser ohne Synchronisierung. Dein CrUX-Dashboard zeigt vielleicht grüne Werte, während deine tatsächlichen Käufer etwas völlig anderes erleben. Deshalb sagt ein bestandener CrUX-Score längst nicht alles aus.

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

Das Problem dabei: Sobald Artikel im Warenkorb landen, ist dein Caching dahin. Und Caching ist genau das, was deine Website schnell macht.

Caching-Plugins deaktivieren das Full-Page-Caching für Nutzer mit dynamischen Inhalten. Schon so etwas Simples wie „Artikel im Warenkorb“ zwingt den Server dazu, die gesamte Seite bei jedem Request komplett neu aufzubauen. Das treibt deine Time to First Byte massiv in die Höhe und verlangsamt direkt Largest Contentful Paint sowie First Contentful Paint.

Die Zahlen sind dramatisch. Auf einer typischen WooCommerce-Website steigt die TTFB von rund 100 ms (gecacht) auf 1.600 ms oder mehr (ungecacht). Das bedeutet eine 16-mal langsamere Server-Antwortzeit, sobald jemand ein Produkt in den Warenkorb legt. Ich habe Fälle erlebt, 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, sobald ein Nutzer etwas in den Warenkorb legt: woocommerce_cart_hash, woocommerce_items_in_cart und wp_woocommerce_session. Sobald ein Caching-Plugin (WP Rocket, LiteSpeed Cache, WP Super Cache) diese Cookies erkennt, umgeht es den Cache für jede einzelne Seite. Nicht nur für die Warenkorbseite. Deine Startseite, deine Produktseiten, deine Kategorieseiten: alles ungecacht. Obendrein feuert WooCommerce bei jedem Seitenaufruf einen AJAX-Request an /?wc-ajax=get_refreshed_fragments ab, um das Mini-Cart-Widget aktuell zu halten. Allein dieser Request kann auf Shared Hosting 2 bis 3 Sekunden dauern.

Das ist einer der Gründe, warum WooCommerce die niedrigste Core-Web-Vitals-Bestehensquote aller großen E-Commerce-Plattformen hat. Laut dem Web Almanac 2025 bestehen auf dem Desktop nur 33 % der WooCommerce-Websites alle drei Core Web Vitals – im Vergleich zu 76 % bei Shopify.

Shopify löst das dank seiner gemanagten CDN-Infrastruktur besser. Doch selbst Shopify kann keine Seiten cachen, die customer- oder cart-Objekte enthalten. Der Unterschied: Die Basis-TTFB von Shopify ist mit rund 0,51 Sekunden bereits so schnell, dass die Einbußen ohne Cache geringer ausfallen.

Magento 2 hat eine clevere Lösung gefunden: Die vollständige Seite wird immer gecacht, selbst für Nutzer mit Warenkorb. Dynamische Inhalte (Mini-Cart, Begrüßung, Lagerbestand) werden clientseitig per AJAX über /customer/section/load/ nachgeladen und im localStorage des Browsers gespeichert. Die Seite selbst bleibt im Full-Page-Cache. Hier wird das „slow by design“-Problem direkt auf Architekturebene gelöst.

Deine besten Kunden bekommen deine schlechtesten Seiten

Die Zahlen machen das schmerzhaft deutlich. Farfetch ermittelte einen Rückgang der Conversion-Rate um 1,3 % für jede 100 ms mehr beim LCP. Blue Triangle stellte einen Einbruch der Conversion-Rate um 40 bis 50 % fest, wenn der LCP von 2 Sekunden auf 4 bis 5 Sekunden steigt.

Ein Besucher surft auf deiner schnellen, gecachten Website. Er findet ein Produkt, das ihm gefällt. Er klickt auf „In den Warenkorb“. Genau in diesem Moment setzt das Caching aus und seine TTFB springt von 100 ms auf 1.600 ms. Ab jetzt ist jede Seite, die er aufruft (Produkte vergleichen, Versand prüfen, zur Kasse gehen), ungecacht. Ausgerechnet die Nutzer mit der höchsten Kaufbereitschaft bewegen sich nun auf der langsamsten Version deiner Website.

Über alle von CoreDash überwachten Websites hinweg sehen wir: Auf selbst gehosteten E-Commerce-Plattformen erleben Nutzer mit Warenkorb eine 3- bis 5-mal schlechtere TTFB als anonyme Besucher. Auf gemanagten Plattformen wie Shopify ist der Abstand geringer (1,5- bis 2-mal), aber immer noch messbar.

So erkennst du das Problem in deinen RUM-Daten

In Lighthouse oder PageSpeed Insights siehst du dieses Problem nicht. Diese Tools testen als anonyme Besucher ohne Cookies. Deine Lab-Scores sehen großartig aus, während deine tatsächlichen Käufer zu kämpfen haben.

Um dieses Problem zu finden, brauchst du Real User Monitoring. Segmentiere deine RUM-Daten danach, ob beim Nutzer ein Warenkorb-Cookie gesetzt ist. Vergleiche TTFB, FCP und LCP zwischen diesen beiden Segmenten. Wenn du einen Unterschied um das 2-Fache oder mehr siehst, ist der Cache-Bypass dein Problem.

In den meisten Analytics-Plattformen kannst du auch nach Seitentyp segmentieren. Vergleiche deine Produktübersichten (meist gecacht) mit deinen Warenkorb- und Checkout-Seiten (nie gecacht). Ein TTFB-Unterschied von mehr als 500 ms zwischen diesen Seitentypen ist ein klares Warnsignal: Deine Server-Wartezeit braucht Aufmerksamkeit.

So optimierst du die Performance für kaufbereite Besucher

Optimiere das Backend, bevor du dich auf Caching verlässt. Verlass dich nicht allein auf Caching-Plugins. Analysiere deinen Backend-Code, optimiere Datenbankabfragen und tune deinen Server, um auch ohne Caching eine schnelle TTFB zu sichern. Eine Website, die ohne Cache langsam ist, wird für Nutzer mit Warenkorb katastrophal langsam sein. Der Cache-Duration-Teil der TTFB sollte nicht die gesamte Last alleine tragen.

Nutze partielles Caching (Fragment Caching). Cache die aufwendigen Teile deiner Seite separat. Produktbeschreibungen, Navigationsmenüs und Footer-Inhalte ändern sich selten. Du kannst sie in Memcached oder Redis cachen, selbst wenn der Full-Page-Cache deaktiviert ist. Ruft ein Nutzer mit Warenkorb eine Seite auf, baut dein CMS sie aus gecachten Fragmenten zusammen, statt alles von Grund auf neu zu generieren. Das kann die ungecachte TTFB um 60 bis 80 % senken.

Rendere dynamische Komponenten clientseitig. Das ist der Ansatz von Magento 2 – und er funktioniert. Liefere den Großteil der Seite als gecachtes HTML aus (serverseitig gerendert). Nutze anschließend JavaScript und einen kleinen API-Call, um die dynamischen Teile (Warenkorb-Anzahl, Begrüßung, personalisierte Empfehlungen) nach dem Laden der Seite abzurufen. Der Browser erhält das schnelle, gecachte HTML sofort. Die dynamischen Teile werden einen Moment später ergänzt. Dein LCP und FCP bleiben schnell, weil sie durch das gecachte Grundgerüst bestimmt werden, nicht durch den dynamischen Inhalt.

Shopifys Headless-Framework (Hydrogen) macht genau das: Produktdaten werden mit langen TTLs aggressiv gecacht, während Warenkorb- und Kundendaten CacheNone() nutzen und nach dem Laden clientseitig abgerufen werden. Dieses Pattern vermeidet außerdem INP-Probleme, weil der dynamische Abruf asynchron abläuft, statt die Nutzerinteraktion zu blockieren.

Implementiere ein effektives Cache-Key-Management. Nutze einfache Keys für statische Elemente (oft reicht die URL als Cache-Key) und komplexe Keys für dynamische Inhalte, die Nutzer-ID, Produkt-IDs und Timestamps enthalten. So kannst du auf Nutzerebene cachen, statt dich zwischen „vollständig gecacht“ und „überhaupt nicht gecacht“ entscheiden zu müssen.

Deaktiviere Cart-Fragmente auf Seiten ohne Warenkorb. Wenn du WooCommerce nutzt, deaktiviere den Aufruf von wc-ajax=get_refreshed_fragments auf allen Seiten, die keinen Mini-Cart anzeigen. Mehrere Performance-Plugins (Perfmatters, FlyingPress) bieten dafür eine Option. Das eliminiert einen 2 bis 3 Sekunden langen AJAX-Call bei jedem Seitenaufruf für Nutzer mit Warenkorb.

Ziehe Edge-Side-Composition in Betracht. Wenn du Cloudflare nutzt, können Workers Seiten an der Edge zusammensetzen: Liefere den gecachten Body der Seite über das CDN aus und binde dynamische Fragmente (Warenkorb, Nutzerdaten) über separate Sub-Requests ein. Cloudflare hat eine Edge-Side-Includes-Implementierung für Workers veröffentlicht, die genau das tut: Deine TTFB bleibt schnell und du lieferst trotzdem personalisierte Inhalte aus.