In short
- Half of the sign-in time was lost between steps, not on the network.
- We removed three steps outright: a redundant request, a second redirect and an interstitial page.
- The result is 840 ms on average — fast enough that users stop perceiving a load at all.
With QR sign-in the user expects one thing: scan, and you are in. Every hundred milliseconds of waiting breaks that feeling. So we measured the whole path, end to end.
Where the time goes
The measurements were not what we expected: the biggest loss was not network latency but waiting between steps. Each step was fast on its own, yet they ran in sequence and the total kept accumulating.
- Session creation: 90 ms.
- Code verification: 120 ms.
- Extra profile request: 210 ms — and it was not needed.
- Two redirects: 380 ms.
What we removed
The profile data already arrived in the verification response, so fetching it with a second call was pointless. The second redirect turned out to be historical debt: the old flow needed an interstitial page, the new one does not.
1.6s
Before (average)
840ms
Now (average)
−3
Steps removed
p95
Under 1.4s
Getting faster is usually not about adding an optimisation. It is about finding a step you can delete.
Result, and what comes next
The average now sits at 840 ms with p95 under 1.4 seconds. Next we want to warm the session while the user is still aiming the camera — opening the connection before verification begins.