checkoutperformancewoocommerce
WooCommerce-Checkout langsam? 9 Ursachen und Fixes
4. November 202610 min Lesezeit·ShopMonitor Team
Loading…
Ein langsamer WooCommerce-Checkout ist etwas anderes als eine träge Shopseite. Viele Tempo-Tipps zielen auf Seiten, die sich cachen und über ein CDN als statische Dateien ausliefern lassen. Beim Checkout geht das nicht. Er braucht eine aktive Session, den Warenkorb, aktuelle Summen und eine Antwort vom Zahlungsanbieter. Wer hier blind Homepage-Tricks übernimmt, gewinnt oft nichts und riskiert im schlimmsten Fall einen gestörten Bestellablauf.
Wasserfalldiagramm eines WooCommerce-Checkouts
Bevor du etwas änderst, brauchst du eine Messung, die dem echten Einkauf entspricht. Zu viele Ratgeber starten mit einem Wert von der falschen Seite. Daraus entsteht schnell eine Liste von Änderungen, die mit dem Kauferlebnis deiner Kunden wenig zu tun hat.
PageSpeed Insights und Lighthouse rufen die URL wie ein neuer anonymer Besucher auf. Ohne Cookies, Session und Warenkorb hat WooCommerce unter /checkout/ kaum etwas zu zeigen. Meist erscheint ein Hinweis zum leeren Warenkorb oder die Weiterleitung zurück zum Warenkorb. Das Tool bewertet genau diesen fast leeren Zustand.
Der Wert kann korrekt sein. Er beschreibt nur nicht den Checkout, den deine Kunden tatsächlich durchlaufen.
Worauf du achten solltest
Die verlässliche Methode dauert rund fünf Minuten und zeigt den Netzwerkverlauf, den Kunden tatsächlich erleben. Teste auf der Live-Seite. In Staging sind Caches oft anders, die Datenbank kleiner und Gateways laufen im Testmodus.
Der letzte Schritt ist geschäftlich entscheidend. Genau dieser Wert fehlt in vielen Audits.
Diese zwei Kennzahlen beantworten unterschiedliche Fragen:
Time to Interactive
Zeit bis zur Bestellung
AJAX-Roundtrips
Verbesserst du den ersten Wert, fühlt sich die Seite reaktionsschneller an. Verbesserst du den zweiten, nimmst du Reibung heraus, nachdem der Kaufentschluss schon gefallen ist.
Jeder Aufruf des Checkouts ist eine neue PHP-Anfrage. WordPress startet, WooCommerce stellt die Session wieder her, der Warenkorb wird berechnet und Versand sowie Steuer werden geprüft. WooCommerce setzt dafür DONOTCACHEPAGE. Die Page-Cache-Trefferquote, mit der Hoster gern werben, sagt also nichts über die Checkout-Geschwindigkeit. Entscheidend ist die Arbeit innerhalb der Anfrage: weniger Plugins auf dieser Seite, ein dauerhafter Object-Cache für wiederholte Abfragen und genug PHP-Worker, damit keine Warteschlange entsteht.
Der klassische Checkout ruft update_order_review auf, sobald sich ein Feld mit Einfluss auf die Summe ändert: Land, Bundesland, PLZ, Versandart, Zahlungsart oder Gutschein. Jeder Aufruf berechnet den Warenkorb neu, prüft Versand und Steuer erneut und baut die Bestellübersicht wieder auf. Eigene Felder können daraus beim Eintippen einer Adresse sechs bis acht Neuberechnungen machen. Prüfe deshalb, welche Felder den Aufruf auslösen, und vermeide ihn bei eigenen Feldern ohne guten Grund. Eigene Checkout-Felder, die in die Neuberechnung eingreifen, sind ein häufiger versteckter Grund, wenn Versandkosten im Checkout falsch wirken oder Summen beim Tippen einer Adresse hinterherhinken.
Gateways kosten an zwei Stellen Zeit. Beim Laden bindet jedes aktive Gateway sein eigenes SDK ein. Express-Buttons erscheinen oft in einem iframe, der erst geladen werden muss. Beim Absenden folgt die Autorisierung als Netzwerkanfrage an den Anbieter. Zwei oder drei aktive Gateways bedeuten somit zwei oder drei SDKs bei jedem Checkout-Aufruf. Aktiviere nur Zahlungsarten, die du wirklich anbietest, und entferne verwaiste Integrationen. Gateway-Skripte solltest du nicht verzögern oder minifizieren. Warum, erklärt der nächste Abschnitt.
Viele Plugins laden ihre Dateien auf der ganzen Website, weil es für Entwickler einfacher ist. So landen Slider, Bewertungs-Widgets, Page-Builder, Popups und Chats auf einer Seite, die sie nicht braucht. Wenn du Dateien gezielt nur im Checkout entfernst, bleibt der Rest des Shops unberührt. Gute Kandidaten sind:
Entferne niemals Dateien von WooCommerce-Core, Zahlungsgateways oder Versand- und Steuer-Integrationen.
Bestelldaten wachsen in genau den Tabellen, in die der Checkout schreibt. Bei der alten Speicherung besteht jede Bestellung aus einer wp_posts-Zeile plus vielen wp_postmeta-Zeilen. Ein Shop mit 50.000 Bestellungen durchsucht damit Metadaten über Millionen Zeilen. Abgebrochene Sessions, abgelaufene Transients und zu viele automatisch geladene Optionen bremsen zusätzlich. Hilfreich sind regelmäßige Datenpflege und eine gut vorbereitete Migration der Bestellspeicherung. Siehe HPOS und Bestelltabellen-Performance für dedizierte Bestelltabellen und eine sichere Migration.
Echtzeit-Tarife von Versanddienstleistern brauchen eine ausgehende HTTP-Anfrage. Der Checkout wartet, bis der Dienst antwortet. Ist der Dienst langsam, wird es auch der Checkout. Bei einem Timeout wartet der Kunde die volle Zeit, manchmal sogar zweimal nach einer Feldänderung. WooCommerce speichert berechnete Tarife je Paket, doch der erste Aufruf einer Session ist immer live. Setze in der Integration ein klares niedriges Timeout, halte Pauschalversand als Alternative bereit und frage nicht unnötig viele Dienstleister gleichzeitig ab.
Adressbasierte Steuerdienste funktionieren ähnlich wie Versand-APIs: Anfrage raus, warten, Summe erst danach. Steuerabfragen laufen oft bei jeder Neuberechnung und verstärken damit Ursache 2. Prüfe, ob das Plugin Ergebnisse nach Adresse und Warenkorb-Hash speichert und ob ein Timeout mit sinnvoller Alternative existiert. Verkaufst du nur in wenigen Regionen mit stabilen Sätzen, vermeiden die eingebauten WooCommerce-Steuertabellen diese Netzwerkwartezeit.
Der Checkout ist meist die PHP-intensivste Seite im Shop. Unterdimensioniertes Hosting fällt deshalb hier zuerst auf. Drei Dinge zählen besonders: die Zahl der PHP-Worker, ein dauerhafter Object-Cache und WordPress-Cron während Seitenaufrufen. Zu wenige Worker erzeugen unter Last eine Warteschlange. Ohne Object-Cache landen wiederholte Abfragen in der Datenbank. Cron kann geplante Aufgaben an die Anfrage eines unglücklichen Kunden hängen. Stelle Cron auf einen echten System-Cron um, aktiviere Object-Caching und vergleiche die Worker-Zahl mit deiner realen gleichzeitigen Last.
Viele Themes überschreiben form-checkout.php und die Bestellübersicht fürs Styling. Manche packen dann Karussells, Trust-Badge-Slider, Upsell-Blöcke oder ein Mega-Menü auf eine Seite, deren Hauptaufgabe das Bezahlen ist. Jedes Extra bringt Markup, CSS und oft JavaScript in den kritischen Pfad. Halte das Checkout-Template bei Formular, Bestellübersicht und Zahlungsbereich. Kürze dekoratives Markup, bevor du breitere WooCommerce-Checkout-Optimierung anfasst, die Caching oder Asset-Bundling betreffen.
Neun Ursachen für einen langsamen WooCommerce-Checkout
| # | Ursache | Typisches Symptom | Wo nachsehen |
|---|---|---|---|
| 1 | Kein Caching möglich | Langsamer erster Aufbau bei jedem Besuch | TTFB im Netzwerkverlauf der DevTools |
| 2 | AJAX-Neuberechnung | Spinner bei den Summen nach jedem Feld | Wiederholte update_order_review-Aufrufe |
| 3 | Gateway-Latenz | Lange Wartezeit nach Bestellung aufgeben | Gateway-SDK-Anfragen und Zeit beim Absenden |
| 4 | Plugin-Ballast | Dutzende unnötige Dateien | Network-Tab, gefiltert auf JS und CSS |
| 5 | Datenbankabfragen | Langsam bei großer Bestellhistorie | Query Monitor und Slow-Query-Log |
| 6 | Live-Versandtarife | Hänger bei einer Adressänderung | Ausgehende Anfragen an Versanddienste und Timeouts |
| 7 | Externer Steuerdienst | Hänger bei jeder Neuberechnung | Plugin-Logs des Anbieters und Cache-Einstellungen |
| 8 | Server-Grenzen | Langsam nur zu Stoßzeiten | PHP-Worker, Object Cache und Cron |
| 9 | Theme-Templates | Schwerer Checkout, leichte Produktseiten | Template-Overrides im Theme |
Hier werden gut gemeinte Maßnahmen schnell zu verlorenen Bestellungen. Diese vier Änderungen wirken nach klassischer Performance-Arbeit, sind im Checkout aber riskant.
Checkout nicht cachen
Zahlungsgateway-Skripte nicht minifizieren oder verzögern
Bereich „Bestellung aufgeben“ nicht lazy loaden
CSS auf dem Checkout nicht blind kombinieren
Cache-Ausschluss hat mehrere Ebenen
Ein Checkout wird selten über Nacht unbrauchbar. Meist wird er mit jedem Plugin-Update, jedem zusätzlichen Gateway und wachsenden Bestellmengen etwas langsamer. Jede Änderung für sich wirkt harmlos. Monate später kommt das erste klare Signal oft als Kundenbeschwerde.
WooCommerce-Checkout-Dauer im Zeitverlauf
Eine Messung ist ein Schnappschuss, kein Trend. Erfasst du dieselben vier Werte in einem festen Rhythmus, erkennst du schleichende Verschlechterungen, bevor Kunden sie melden:
Der vierte Punkt macht aus einem langsamen Monat einen brauchbaren Ausgangspunkt für die Diagnose. Springt die Dauer zwischen zwei Läufen, ist die Änderung an Plugin, Theme oder Gateway dazwischen dein erster Prüfpunkt. Führe dieselben Checks durch wie bei falschen Versandkosten im Checkout, denn falsch konfigurierte Zonen und Carrier-Timeouts zeigen sich oft zuerst als Checkout-Verzögerung.
Ein manueller Wochenlauf ist oft die erste Pflegeaufgabe, die verschwindet. ShopMonitor führt den Checkout nach Zeitplan in einem echten Browser aus und protokolliert die Dauer jedes Laufs. So erkennst du einen schleichend langsamer werdenden Checkout in deinen Daten statt erst im Support-Ticket. ShopMonitor überwacht den Checkout. Es ist kein Performance-Optimizer. ShopMonitor repariert kein langsames Gateway, zeigt dir aber, wann der Browser-Checkout langsamer geworden ist. Künftig testet ShopMonitor zusätzlich die Zustellung transaktionaler E-Mails. Wenn du den Ablauf erst selbst durchführen willst, lies unseren Leitfaden zum Checkout testen.
ShopMonitor prüft Checkout und Formulare täglich im Browser und warnt dich, wenn etwas bricht. Kein Code. Keine Plugins. Einrichtung in fünf Minuten.
Keine Kreditkarte nötig.
Über die Autoren
Verfasst von Winning Solutions, dem Team hinter ShopMonitor. ShopMonitor macht langsamer werdende Checkouts mit geplanten Browser-Tests über die Zeit sichtbar, auch wenn ein PageSpeed-Test mit leerem Warenkorb sie nicht erfassen kann.