Checkout-Tempo: die letzten Sekunden vor der Bestellung

Zum Warenkorbabbruch gibt es im Onlinehandel besonders viele Erhebungen. Aus 50 verschiedenen Studien errechnet das Baymard Institute einen Mittelwert von 70,22 Prozent (Baymard Institute): Gut sieben von zehn gefüllten Warenkörben führen nicht zur Bestellung. Der Wert mittelt über sehr verschiedene Branchen, Zeiträume und Messmethoden und taugt deshalb nicht als Zielmarke für einen einzelnen Shop - eine Fachhandelsseite mit Konfigurator liegt anders als ein Abo-Shop mit drei Artikeln. Als Größenordnung sagt er aber deutlich, wo das Geld liegt: hinter dem Warenkorb, nicht davor. Wer das in Euro übersetzen möchte, findet die Rechnung im Beitrag zu Ladezeit, Conversion-Rate und Umsatz.

Ein Teil dieser Abbrüche hat mit Tempo nichts zu tun: Vergleichen, Parken, Versandkosten, fehlende Zahlungsart. Ein messbarer Teil hat es doch. 17 Prozent der US-Onlinekäufer haben in der Checkout-Untersuchung des Instituts schon einmal eine Bestellung abgebrochen, weil der Checkout zu lang oder zu kompliziert war (Baymard Institute). Länge und Kompliziertheit sind dabei keine reinen Gestaltungsfragen. Eine Adressprüfung, die nach jedem Tastendruck 800 Millisekunden braucht, macht dasselbe Formular subjektiv doppelt so lang: Die Feldzahl bleibt gleich, die gefühlte Arbeit verdoppelt sich. Wahrgenommene Kompliziertheit ist deshalb zu einem guten Teil eine Frage der Laufzeit im Browser und nicht nur eine Frage des Layouts.

Wie stark Tempo für sich genommen wirkt, zeigt eine Untersuchung über 37 Marken mit rund 30 Millionen mobilen Sitzungen: Erhoben und ausgewertet hat die Daten Fifty-Five im Auftrag von Google, den Bericht dazu hat Deloitte Ireland erstellt (Milliseconds Make Millions, 2020). Grundlage war eine natürliche Verbesserung der mobilen Ladezeit um 0,1 Sekunden. Im Handelssegment - 15 Marken mit 20,5 Millionen Sitzungen - stiegen die Conversions um 8,4 Prozent, der durchschnittliche Bestellwert um 9,2 Prozent (Deloitte Ireland 2020). Die Erhebung lief über vier Wochen und zeigt eine Korrelation für die untersuchten Marken; sie ist keine Rechenregel, die sich auf jeden Shop übertragen lässt. Sie beschreibt aber die Richtung sehr deutlich: Zehntelsekunden sind im Handel keine Kosmetik, sondern eine wirtschaftliche Größe.

Die Tabelle erklärt, warum ein Tempo-Projekt am Checkout anders abläuft als eines an der Startseite. Dort geht es um Bilder, Schriften und renderblockierende Ressourcen; hier um Datenbankabfragen, fremde Rahmen und Zeit auf dem Hauptthread. Beide Enden brauchen eigene Messpunkte, und beide gehören in dasselbe Bild aus Frontend-Optimierung und Serverarbeit, sonst wird an der falschen Stelle gespart. Wohin die Serverzeit im Einzelnen fließt, macht der Beitrag zu Server-Timing sichtbar - ohne diese Aufschlüsselung bleibt eine hohe Antwortzeit eine Zahl ohne Adresse.

Der durchschnittliche Checkout enthält 11,3 Formularfelder, obwohl nach der Untersuchung des Instituts für die meisten Shops 8 Felder genügen würden (Baymard Institute). Der Wert ist über die Jahre gesunken - 2021 waren es 11,8 Felder, 2019 noch 12,7 (Baymard Institute) -, doch der Abstand zum Notwendigen ist geblieben. Jedes zusätzliche Feld kostet zweimal: einmal Aufmerksamkeit beim Ausfüllen und einmal Laufzeit im Browser. Der erste Posten ist bekannt, der zweite wird selten beziffert.

Ein Feld bringt in typischen Shop-Themes mehrere Ereignisbehandler mit, oft eine Prüfung je Tastendruck, manchmal eine Anfrage an den Server für die Adressvervollständigung. Bei elf Feldern summiert sich das zu einer dauerhaften Grundlast auf dem Hauptthread - und genau diese Grundlast misst die Reaktionszeit auf Eingaben. Wer die Zahl der Felder senkt, senkt beide Kosten gleichzeitig. Wo sich Felder nicht streichen lassen, weil das Geschäft sie braucht, hilft der Umbau der Prüfung: vom Tastendruck auf das Verlassen des Feldes, und lange Aufgaben aufteilen, wie im Beitrag zu langen Aufgaben und der Scheduler-Schnittstelle beschrieben.

Der Zahlungsschritt ist in der Regel der Schritt, in dem fremder Code im eigenen Kaufprozess läuft. Der eingebettete Rahmen des Zahlungsdienstleisters bringt eigenes JavaScript mit, lädt eigene Schriften und misst sich selbst nicht mit. Für die Seite bedeutet das drei Dinge: zusätzliche Zeit auf dem Hauptthread, zusätzliche Verbindungen und ein Element, dessen Höhe erst nach dem Laden feststeht. Genau daraus entstehen Layoutsprünge unmittelbar vor dem Bezahlen - der Bestellknopf rutscht nach unten, während der Daumen schon unterwegs ist. Wie sich das vermeiden lässt, beschreibt der Beitrag zu Layoutsprüngen im Shop.

Der Aufwand lohnt sich, weil im Zahlungsschritt alles zusammenkommt: fremder Code, Formularlogik und eine Serverantwort, die sich nicht vorbereiten lässt. Wie viel fremden Code ein Shop insgesamt trägt, klärt der Beitrag zum Entschlacken von Drittanbieter-Skripten; wie sich derselbe Checkout unter hoher Last verhält, zeigt ein Lasttest vor der Hochsaison. Beides gehört zusammen, denn eine Antwortzeit aus einer ruhigen Nacht sagt wenig über einen Freitagabend im Dezember.

Für die Praxis heißt das: fünf Messpunkte statt einem, ein Budget je Schritt und eine Aufzeichnung, die auch die Fehlerwege erfasst. Der Rest ist Handwerk - Abfragen zusammenfassen, Felder streichen, Prüfungen entzerren, fremde Rahmen bändigen. Welche Core Web Vitals dabei welchen Schritt beschreiben und wie stark die Laufzeit von CSS im Browser dazwischenfunkt, vertieft der Beitrag zur Style-Recalculation. Wer beides zusammen betrachtet, kommt in der Regel mit weniger Umbau aus als erwartet.