Kaufabbrüche senken, Checkout beschleunigen

Wo der Magento Checkout hakt

Ein Standard-Magento-2-Checkout hat vier Schritte: Warenkorb, Lieferadresse, Versandmethode und Zahlung. Jeder Schritt rendert über Knockout.js-Komponenten, die erst rendern, wenn das JavaScript-Bundle vollständig ausgeführt wurde. Auf einer durchschnittlichen Mobilverbindung ist das spürbar.

• ▸Knockout.js Render-Verzögerungen: Die Checkout-Seite lädt ein schweres JS-Bundle, bevor Kunden etwas ausfüllen können. Auf Slow 4G sind das über 3 Sekunden bis zur ersten Interaktion.
• ▸Adressvalidierungs-Roundtrips: Jeder Tastendruck im Adressfeld löst eine Server-Anfrage zur Validierung aus. Bei hoher TTFB fühlt sich das wie Ruckeln an.
• ▸Payment-Method-JS-Bundling: Zahlungsmethoden laden ihre eigenen Skripte erst, wenn Kunden Schritt 4 erreichen. Diese Verzögerung tritt zum ungünstigsten Zeitpunkt auf.
• ▸Keine sanfte Validierung zwischen Schritten: Kunden, die ein Feld falsch ausfüllen, merken es erst beim Klick auf Weiter. Der Fehler erscheint oben auf der Seite, weit entfernt vom betreffenden Feld.
• ▸Keine Wiederherstellung nach fehlgeschlagener Zahlung: Schlägt eine Zahlung fehl, landet der Kunde auf einer generischen Fehlerseite ohne vorausgefüllte Daten. Viele Kunden verlassen den Shop an diesem Punkt.
• ▸Gastkasse nicht prominent im Flow: Ein Konto anlegen wird standardmäßig über die Gastkasse gestellt, was für mobile Käufer eine zusätzliche Hürde bedeutet.

Das sind keine Bugs. So funktioniert Magento 2 Checkout standardmäßig. Die Probleme häufen sich in einem durchschnittlichen Shop mit einigen Zahlungsmethoden und einer oder zwei Adressvalidierungs-Extensions.

Die messbare Auswirkung auf deinen Funnel

Kaufabbruchraten von 70 Prozent oder höher im Checkout sind für Magento-Shops keine Ausnahme. Branchendurchschnittswerte liegen bei 70 bis 75 Prozent. Aber nicht alle abgebrochenen Warenkörbe sind Käufer, die ihre Meinung geändert haben. Ein Teil verlässt den Checkout, weil es zu langsam geht, ein Formular nicht abgeschickt werden kann, oder eine Zahlungsmethode erst im letzten Schritt sichtbar wird.

Die informativste Messung ist die Drop-off-Rate pro Schritt in GA4 Enhanced Ecommerce. Wo brechen Kunden ab: beim Ausfüllen der Adresse, bei der Wahl der Versandmethode oder beim Zahlungsschritt? Diese Daten bestimmen, wo der Gewinn liegt. INP auf der Checkout-Seite selbst ist ein zweiter Indikator: Ein INP über 200 ms auf den Formularfeldern bedeutet, dass Kunden bei jeder Eingabe eine spürbare Verzögerung wahrnehmen.

Bei CarCare24 lag der CrUX-INP für den Checkout nach den Performance-Optimierungen bei 111 ms. Das ist unter der 200-ms-Grenze. Für einen Checkout mit Knockout.js ist das mit gezielten Anpassungen an der Skript-Ladereihenfolge und dem Vermeiden von synchronen XHR-Aufrufen in der Validierungslogik erreichbar.

Wie ich den Checkout auditiere

Ein Checkout-Audit beginnt mit Daten, nicht mit Annahmen. Ich schaue auf drei Quellen: den GA4-Enhanced-Ecommerce-Funnel, Session-Recordings von Hotjar oder Microsoft Clarity und CrUX-Daten für den /checkout-Pfad.

• ▸GA4 Enhanced Ecommerce Funnel: Schritt-für-Schritt-Drop-off-Rate pro Gerätetyp. Mobile Besucher brechen häufiger beim Adressformular ab, Desktop-Besucher häufiger beim Zahlungsschritt.
• ▸Session Recordings: Hotjar oder Microsoft Clarity zeigen, wo Kunden zögern, zurückgehen oder nach einem Validierungsfehler abbrechen. Das macht Annahmen über das Verhalten überflüssig.
• ▸CrUX INP für /checkout: Der Chrome User Experience Report zeigt die tatsächliche Interaktionsverzögerung auf der Checkout-Seite, gemessen bei echten Besuchern über 28 Tage.
• ▸Payment-Provider-Logs: Mollie- oder Stripe-Logs geben Aufschluss darüber, wie viele Zahlungen gestartet werden, wie viele beim ersten Versuch scheitern und wie viele Kunden nach einer fehlgeschlagenen Zahlung zurückkehren.
• ▸Network Waterfall auf der Checkout-Seite: Welche Skripte werden synchron geladen, welche Zahlungsmethoden-Skripte warten nicht auf einen User-Trigger, und wie hoch ist die TTFB beim Erstellen des Warenkorbs.
• ▸Adressvalidierungs-Extension-Analyse: Welche Extension übernimmt die Adressvalidierung, wie viele Anfragen sendet sie pro Eingabe, und ist ein Debounce vorhanden.

Aus diesen Quellen entsteht eine priorisierte Liste von Engpässen mit geschätzter Conversion-Auswirkung. Erst dann entscheidest du, welche Fixes in den Scope kommen.

Was ich typischerweise am Magento Checkout anpasse

Nach dem Audit implementiere ich die Fixes mit dem höchsten Einfluss auf Drop-off und INP. Bei Magento-Shops ist es fast immer eine Kombination der folgenden Anpassungen:

• ▸1-Page-Checkout: Alle Schritte auf einer einzigen Seite ohne Seitenreloads zwischen Adresse, Versand und Zahlung. Die Knockout.js-Komponenten werden sofort geladen, ohne schrittweise Navigation.
• ▸Inline-Validierung mit sanften Fehlermeldungen: Validierungsfehler erscheinen direkt neben dem Feld, nicht erst nach dem Klick auf Weiter. Bei einem Fehler bleibt der Fokus auf dem Feld.
• ▸Asynchrones Payment-Method-Loading: Zahlungsmethoden werden asynchron geladen, sobald die Checkout-Seite öffnet, nicht erst bei Schritt 4. Kunden sehen die Optionen früher und können eine Wahl treffen, während sie die Adresse ausfüllen.
• ▸Adressautovervollständigung via Postcode.nl oder PDOK: PLZ plus Hausnummer reichen für niederländische Adressen. Straße und Ort werden automatisch ausgefüllt, was das Formular verkürzt und Validierungsfehler reduziert.
• ▸magento_persistent.php für die Wiederherstellung nach fehlgeschlagener Zahlung: Schlägt eine Zahlung fehl, werden Adressdaten und die gewählte Zahlungsmethode in der Session gespeichert. Kunden müssen nicht von vorne anfangen.
• ▸Gastkasse als primäre Option: Das Konto-Anlegen-Prompt wird nach dem Kauf verschoben, als Teil der Bestellbestätigung. Auf Mobilgeräten reduziert das den Eingabepfad erheblich.

Welche dieser Anpassungen zutreffen, hängt von deinem Extension-Set und der Magento-Version ab. Bei Magento 2.4.6 oder höher sind einige Optionen direkt über die Konfiguration verfügbar. Bei älteren Versionen sind gezielte Patches oder Custom-Module erforderlich.

Was ich nicht tue

Es gibt schnelle Wege, einen Checkout besser aussehen zu lassen, ohne die eigentlichen Engpässe zu beheben. Ich nutze sie nicht.

• ✕OneStepCheckout-Extensions ohne eigene Bewertung installieren: Es gibt Dutzende One-Step-Checkout-Extensions für Magento. Einige sind gut gebaut, viele nicht. Sie fügen ihren eigenen JavaScript-Stack hinzu, der das bestehende Bundle belastet. Ich installiere keine Extension, die ich nicht vorher auf Bundle-Impact und Konflikte mit bestehenden Modulen analysiert habe.
• ✕Headless Checkout ohne breiteren Architekturkontext: Ein von Magento-Backend entkoppelter React- oder Next.js-Checkout klingt attraktiv, erfordert aber eine stabile GraphQL- oder REST-API, korrekt konfiguriertes CORS und ein solides Verständnis des Magento-Quote-und-Order-Flows. Ich mache das nur, wenn die breitere Shop-Architektur das unterstützt.
• ✕Custom-Payment-Provider-Integrationen ohne Kundenforschung: Eine neue Zahlungsmethode hinzuzufügen, die deine Kunden nicht nutzen, löst kein Conversion-Problem. Ich schaue zuerst auf den Drop-off pro Zahlungsmethode in den GA4-Daten.
• ✕Score-Chasing ohne Funnel-Kontext: Ein INP von 150 ms versus 111 ms ist weniger relevant, wenn die Gastkasse schwer zu finden ist. Ich priorisiere nach Funnel-Impact, nicht nach technischer Perfektion.

Wenn eine Extension oder Vorgehensweise außerhalb meiner Beurteilung liegt, sage ich das direkt. Ein ehrliches Nein ist besser als eine Implementierung, die später mehr Probleme schafft als löst.

Verwandte Seiten