Eine Seite, die auf dem Smartphone 3 Sekunden zum Laden braucht, verliert rund 53 % der mobilen Besucher, bevor Produktinhalte sichtbar werden (gemäß Googles veröffentlichten Daten zu mobilen Abbruchschwellen).
Von denen, die bleiben, geht mit jeder weiteren Sekunde Ladezeit eine Conversion-Rate-Einbuße von rund 7 % einher, konsistent über mehrere Commerce-Studien hinweg (Akamai, Google, Portent). Bei einem Shop mit €10.000 monatlichem Umsatz bedeutet das €700 verlorenen Umsatz pro Monat für jede zusätzliche Sekunde Ladezeit.
Keine andere Art von Website hat bei schwacher Performance so viel zu verlieren und bei deren Behebung so viel zu gewinnen wie ein Onlineshop.
Die Zahlen hinter der Geschwindigkeit
Der Zusammenhang zwischen Seitengeschwindigkeit und Umsatz ist umfangreich untersucht worden. Die Ergebnisse sind branchenübergreifend und zeitlich stabil:
| Studie / Quelle | Ergebnis |
|---|---|
| Google / Deloitte (2019) | 0,1 Sekunden Verbesserung → 8 % höhere Conversion-Rate auf Mobilgeräten |
| Amazon (intern) | 100 ms Verzögerung = 1 % Umsatzverlust |
| Walmart (intern) | 1 Sekunde Verbesserung → 2 % mehr Conversions |
| Portent (2019) | Seiten, die in 1 Sekunde laden, konvertieren 3× besser als Seiten, die 5 Sekunden brauchen |
Dabei handelt es sich nicht um Einzelbefunde aus günstigen Bedingungen. Sie stammen aus groß angelegten Echtdaten über Millionen von Transaktionen. Die Richtung ist immer dieselbe: schneller bedeutet mehr Umsatz.
Warum mobiles E-Commerce eine eigene Kategorie ist
Mehr als 70 % des E-Commerce-Traffics kommt heute von Mobilgeräten. Trotzdem liegt die mobile Conversion-Rate bei rund 2 %, verglichen mit etwa 4 % auf dem Desktop. Diese Lücke, die branchenweit Milliarden an nicht realisiertem Umsatz repräsentiert, erklärt sich überwiegend durch Geschwindigkeit und Usability auf dem Smartphone.
Mobilfunkverbindungen sind nicht einheitlich. 4G-Abdeckung ist lückenhaft, besonders in ländlichen Gebieten. Günstigere Android-Geräte, die einen erheblichen Marktanteil ausmachen, haben langsamere Prozessoren, die mit JavaScript-lastigen Seiten kämpfen. Eine Produktseite, die auf einem neuen iPhone in der Innenstadt akzeptabel lädt, kann für einen nennenswerten Teil der tatsächlichen Kunden faktisch unbrauchbar sein.
Auch das Interaktionsmodell ist ein anderes. Navigation mit dem Daumen, kleine Tippziele und für den Desktop konzipierte Checkout-Formulare erzeugen Reibung. Kommt eine langsam ladende Seite hinzu, steigen die Abbruchraten schnell an.
- 70 %+ des E-Commerce-Traffics läuft über Mobilgeräte, die Conversion-Rate liegt dort aber nur bei etwa der Hälfte des Desktops
- 4G-Verbindungen variieren erheblich nach Standort und Gerätequalität
- Günstigere Geräte repräsentieren einen großen Teil der tatsächlichen Nutzer, keine Randgruppe
- Checkout-Reibung auf dem Smartphone potenziert sich, wenn die Seite langsam reagiert
Core Web Vitals und ihre Bedeutung für Ihren Shop
Google misst die Seitenperformance anhand eines Metrik-Sets namens Core Web Vitals. Jede Metrik entspricht direkt einem Erlebnis Ihrer Kunden beim Einkaufen:
| Metrik | Was gemessen wird | E-Commerce-Relevanz | Gut | Verbesserungsbedarf | Schlecht |
|---|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Wie lange bis der Hauptinhalt sichtbar ist | Ihr Hero-Produktbild oder Featured-Banner | Unter 2,5 s | 2,5 s bis 4 s | Über 4 s |
| INP (Interaction to Next Paint) | Wie schnell die Seite auf Klicks und Tippen reagiert | In-den-Warenkorb-Button, Filterauswahl, Mengenänderungen | Unter 200 ms | 200 ms bis 500 ms | Über 500 ms |
| CLS (Cumulative Layout Shift) | Wie stark die Seite beim Laden springt | Produktlisten, die verschieben, wenn Bilder nachladen | Unter 0,1 | 0,1 bis 0,25 | Über 0,25 |
Seiten, die bei allen drei Core Web Vitals grün abschneiden, erhalten einen Ranking-Boost in Googles Suchergebnissen. Seiten, die scheitern, werden nach unten gedrängt. Ein langsamer Shop wird also doppelt bestraft: geringere organische Sichtbarkeit und niedrigere Conversion-Rate bei dem Traffic, der trotzdem ankommt.
Ein schlechter INP-Wert ist bei einem Onlineshop besonders schädlich. Tippt ein Kunde auf "In den Warenkorb" und eine halbe Sekunde passiert nichts, tippen viele ein zweites Mal oder verlassen die Seite in der Annahme, sie sei defekt.
WooCommerce und das Plugin-Problem
WooCommerce betreibt einen großen Teil der Onlineshops und ist gleichzeitig eine der performance-schwächsten Plattformen im Skalierungsbereich. Ein funktionierender WooCommerce-Shop läuft typischerweise mit 50 bis 80 Plugins. Jedes davon fügt HTTP-Requests, JavaScript-Ausführungszeit und CSS-Overhead hinzu.
Das Ergebnis auf Seitenebene:
- Produktseiten übertragen beim ersten Laden typischerweise 4 bis 8 MB Daten
- Eine Standard-WooCommerce-Produktseite kann 100+ Datenbankabfragen auslösen
- JavaScript-Bundles aus mehreren Plugins blockieren häufig das Rendering
- Drittanbieter-Skripte (Bewertungen, Live-Chat, Analytics) verlängern die Request-Kette
- WooCommerce-LCP auf Mobilgeräten liegt in webvise-Audits typischerweise bei 4 bis 6 Sekunden; Ergebnisse variieren je nach Theme und Plugin-Auswahl.
Der LCP-Bereich von 4 bis 6 Sekunden liegt tief im schlechten Bereich auf Googles Skala und weit jenseits der Abbruchschwelle für die meisten mobilen Nutzer. Caching-Plugins reduzieren das Symptom, ändern aber nichts an der zugrundeliegenden Architektur, die das Problem erzeugt.
Das Datenbankabfrage-Problem ist strukturell. WooCommerce baut Produktseiten bei jedem Request dynamisch auf: Produktdaten, Preisregeln, Lagerbestand, verwandte Produkte und Warenkorb-Status werden jedes Mal neu aus der Datenbank geladen. Bei 100+ Abfragen pro Seitenaufruf stoßen selbst schnelle Hosting-Umgebungen an ihre Grenzen.
Wie ein performance-optimierter E-Commerce-Stack aussieht
Eine Headless-Commerce-Architektur trennt das Frontend, also das, was Kunden sehen und bedienen, vom Commerce-Backend, das Produkte, Lagerbestand und Bestellungen verwaltet. Das Frontend wird in Next.js gebaut und zum Build-Zeitpunkt vorgerendert. Das Backend (Shopify, BigCommerce oder WooCommerce headless) wickelt Transaktionen per API ab.
Der Performance-Unterschied ist strukturell, nicht kosmetisch:
- Statische/ISR-Produktseiten: zum Build-Zeitpunkt vorgerendert und direkt vom CDN-Edge ausgeliefert, kein PHP, keine Datenbankabfragen beim Laden
- Lazy-geladene Produktbilder: nicht sichtbare Bilder laden erst bei Bedarf, in modernen Formaten (WebP, AVIF), die bei vergleichbarer Qualität 30 bis 50 % kleiner sind als entsprechende JPEGs (Cloudinary- und Web.dev-Messungen)
- Minimales JavaScript: kein jQuery, kein volles Bootstrap, tree-geshakte Bundles, die nur den Code liefern, den die jeweilige Seite tatsächlich benötigt
- Incremental Static Regeneration: Produktseiten aktualisieren sich automatisch bei Lager- oder Preisänderungen, ohne vollständigen Rebuild
| Metrik | WooCommerce (typisch) | Next.js Headless (typisch) |
|---|---|---|
| LCP (Mobilgerät) | 4 bis 6 Sekunden | Unter 1,5 Sekunden |
| Time to Interactive | 6 bis 10 Sekunden | Unter 2 Sekunden |
| Seitengewicht (Produktseite) | 4 bis 8 MB | Unter 500 KB |
| Lighthouse-Score (Mobilgerät) | 25 bis 45 | 90 bis 98 |
Diese Wertebereiche spiegeln typische Ergebnisse aus webvise-Audits wider; konkrete Resultate hängen von Theme, Plugin-Set, Bildgewicht und Drittanbieter-Skripten ab.
Die Conversion-Rechnung für Ihren Shop
Führen Sie die Kalkulation für Ihren eigenen Shop durch.
Das Schema ist einfach:
- Aktuellen monatlichen Umsatz nehmen
- Aktuelle Conversion-Rate schätzen (Bestellungen geteilt durch Sessions)
- Erwartete Verbesserung durch ein Speed-Uplift ansetzen
- Daraus resultierenden Umsatzanstieg berechnen
Illustratives Szenario: Ein Performance-Rebuild, der die Conversion-Rate bei einem Shop mit €15.000/Monat Umsatz und gleichem Traffic von 1,5 % auf 2,1 % anhebt, ergibt bei €100 durchschnittlichem Bestellwert rund €6.000/Monat an zusätzlichem Umsatz. Tatsächliche Ergebnisse hängen vom Ausgangswert ab.
Selbst eine konservativere Verbesserung kann die Rebuild-Kosten spürbar amortisieren; der Rückzahlungszeitraum hängt von Traffic-Volumen und durchschnittlichem Bestellwert ab.
Die Kalkulation funktioniert auf jedem Umsatzniveau. Ein Shop mit €5.000/Monat, der 0,5 Prozentpunkte in der Conversion-Rate gewinnt, erzielt €1.667/Monat mehr. Ein Shop mit €50.000/Monat gewinnt mit denselben 0,5 Prozentpunkten €16.667/Monat.
Was zuerst zu messen ist
Vor jeder Veränderung steht die Bestandsaufnahme. Vier Tools decken das Wesentliche ab:
- Google PageSpeed Insights: Produktseiten-URL eingeben (nicht nur die Startseite) und einen Score von 0 bis 100 auf Mobilgeräten erhalten. Unter 50 ist dringend. Unter 30 bedeutet, dass Kunden die Seite aktiv wegen der Ladezeit verlassen.
- Google Search Console → Core Web Vitals: zeigt Echtnutzer-Daten von tatsächlichen Besuchern, keine Laborbedingungen. Rote URLs hier sind live Umsatzverluste.
- Lighthouse (Chrome DevTools): im Inkognito-Modus auf der Produktseite ausführen. Das LCP-Element prüfen: Ist es das Haupt-Produktbild? Ist es als lazy-loaded markiert? Das sollte es nicht sein.
- Netzwerk-Tab (Chrome DevTools): Requests nach Größe sortieren. Nach großen unkomprimierten Bildern, render-blockierenden Skripten und Drittanbieter-Requests suchen, die die Ladezeit verlängern.
Besondere Aufmerksamkeit verdient das LCP-Element. Ist das Hero-Produktbild lazy-geladen, was in theme-basierten WooCommerce-Setups häufig vorkommt, kann allein diese Änderung, das Entfernen des Lazy-Load-Attributs vom ersten sichtbaren Bild, den LCP sofort um 1 bis 2 Sekunden verbessern.
Quick Wins vor einem vollständigen Rebuild
Steht ein vollständiger Rebuild nicht unmittelbar auf der Agenda, können diese Maßnahmen die Performance im bestehenden Setup verbessern:
- Bildkomprimierung und WebP-Konvertierung: Produktbilder auf WebP umstellen reduziert die Bildgröße um 40 bis 60 %. Tools wie Imagify oder ShortPixel erledigen das automatisch.
- Ungenutzte Plugins entfernen: ein Plugin-Audit durchführen. Jedes installierte Plugin, auch deaktivierte, erzeugt Overhead. Alles löschen, was nicht aktiv benötigt wird.
- Seiten-Caching aktivieren: WP Rocket oder W3 Total Cache reduzieren den Aufwand für die dynamische Seitengenerierung. Das behebt die Architektur nicht, verringert aber die Auswirkungen bei Wiederholungsbesuchen.
- Hosting upgraden: Shared Hosting setzt der Performance eine harte Obergrenze. Der Wechsel zu verwaltetem WordPress-Hosting (Kinsta, WP Engine, Cloudways) bringt typischerweise 10 bis 20 Lighthouse-Punkte.
- Nicht-kritisches JavaScript verzögern: Die meisten Themes laden alle Skripte auf jeder Seite. Skripte, die beim initialen Laden nicht benötigt werden, zu verzögern reduziert die render-blockierende Zeit.
Diese Maßnahmen verlängern die nutzbare Lebensdauer einer Website und können einen Score von 35 auf 55 anheben. Die strukturelle Obergrenze ändern sie nicht. Ein WooCommerce-Shop mit vollem Plugin-Stack, dynamischer Seitengenerierung und geteilter Datenbank wird auf Mobilgeräten unabhängig vom Konfigurationsaufwand nicht 85+ erreichen.
Für Shops mit nennenswertem monatlichen Umsatz sind das Verzögerungstaktiken. Der strukturelle Fix, ein Headless-Rebuild, ist es, was dauerhaft Wirkung zeigt.
Wann ein Performance-Rebuild finanziell sinnvoll ist
Die Faustregel: Liegt der monatliche Umsatz über €5.000 und der mobile PageSpeed-Score unter 60, amortisiert sich ein Performance-Rebuild bei diesem Traffic-Niveau typischerweise binnen 6 Monaten. Das ist eine Heuristik, keine Garantie.
Bei €10.000/Monat und einer typischen Conversion-Rate-Verbesserung von 0,4 bis 0,6 Prozentpunkten vor dem Rebuild beläuft sich das monatliche Uplift auf €400 bis 600. Rebuild-Kosten von €3.000 bis 5.000 amortisieren sich in 6 bis 10 Monaten, ohne etwaige Verbesserungen im organischen Suchranking durch bessere Core Web Vitals einzurechnen.
Shops über €20.000/Monat mit schwachen Performance-Scores lassen jeden Monat erhebliches Conversion-Potenzial ungenutzt. Der Amortisationszeitraum liegt oft unter 3 Monaten.
Den genauen Stand Ihres Shops ermittelt ein kostenloser Website-Health-Report unter webvise.io/wp-health-report. Er analysiert Ihre Core Web Vitals, benennt die wirkungsstärksten Performance-Probleme und zeigt klar, was ein Rebuild konkret verändern würde. Keine Registrierung erforderlich.