Den Checkout auf Tempo umgebaut

Das ist die Fortsetzung von den Ablauf auf drei Screens kürzen: derselbe Checkout, ein Jahr später, richtig gemessen. Das Dashboard sagte, er sei schnell. Das Support-Postfach sagte etwas anderes, und das Support-Postfach hatte recht. Denn das Dashboard zeigte einen Median, und über einen Median beschwert sich niemand.

p50 vorher

1,1 s

und es blieb 1,1 s danach

p95 vorher

4,6 s

Verkaufsspitze, mobil

p95 nachher

2,2 s

gleiche Bedingungen

Erst den Ausläufer finden, dann die Leute darin#

Den p95 nach Gerät und Zeitpunkt aufzuteilen brachte die Antwort in etwa zehn Minuten: fast ausschliesslich Telefone, fast ausschliesslich in den ersten vier Minuten eines Verkaufsstarts. Also genau die Gruppe, für die der Kauf am wichtigsten war.

Die vier Änderungen#

1. 01
   Ein kleinerer kritischer Pfad

   Die Checkout-Route importierte den Saalplan-Renderer, den sie längst nicht mehr zeigte. Neunzig Kilobyte JavaScript, geparst vor dem ersten Bild, auf einem Gerät, das sie nie ausführen würde.

2. 02
   Das Zahlungsfenster, früher

   Wir legen die Zahlungsabsicht jetzt an, während die Käuferin noch bestätigt, und nicht danach. Springt sie ab, wird sie storniert. Dieser eine Schritt nahm rund 600 ms vom Ausläufer, weil er einen Netz-Roundtrip mit einem Menschen überlappt, der einen Screen liest.

3. 03
   Ein Roundtrip statt drei

   Reservation, Preis und Gebührenauflösung waren drei aufeinanderfolgende Aufrufe, von denen jeder die Id des vorherigen brauchte. Sie sind jetzt ein Endpunkt, der alle drei in einer Transaktion erledigt.

4. 04
   Ehrliches Warten

   Wo sich ein Warten nicht vermeiden liess, sagt der Button jetzt, was passiert: «Platz wird reserviert», dann «Zahlung läuft». Das macht nichts schneller; es hat messbar die Doppelklicks reduziert, und das machte sehr wohl etwas schneller.

Was nicht funktioniert hat#

• Die Checkout-Route beim Hover vorladen. Echte Käuferinnen auf dem Telefon hovern nicht, und der Gewinn auf dem Desktop lag im Rauschen.
• Ein Skeleton fürs Zahlungsfenster. Es liess das Warten im Test länger wirken: Ein Skeleton verspricht, dass Inhalt kommt, und was kommt, ist ein iframe eines Dritten mit eigenem Timing.
• Das CSS abspecken. Zwölf Kilobyte gespart, keine messbare Änderung. Der kritische Pfad war JavaScript, und wir haben zwei Tage gebraucht, um das auf die harte Tour zu bestätigen.