Performance, part 2
In the previous article, we’ve seen how we sped up our “Share” pipeline by reducing task latencies and shifting tasks to the left on the waterfall timeline.
The pivotal event that unlocks the transfer is when the mobile device detects and reads the QR code displayed on the computer’s web page. This happens at the right edge of the “Scan” task. The QR code contains the routing ID of the target web page, and the second cryptographic key involved in our end-to-end encryption system. No data can be pushed to the target web page before we know which routing ID to forward to, right?
Or maybe we can try to guess?
Here’s a heuristic: if a given mobile M has recently shared a picture to a target browser B, and the same target B is currently listening to a new routing ID T, then a new share action from M has a good chance of targeting T. We can give it a shot and send something to T, even before the QR code has been scanned! The goal is to shift the “Download” task to the left, if feasible.
We want to implement this probabilistic optimization while respecting the core principles of the system:
- Privacy: Only the actual target, whose QR code is effectively scanned, is allowed to receive both the shared resource encrypted payload and the decryption keys. No other targets or servers may have the decryption keys.
- Decoupling: The mobile has no information about the target computer, and vice versa.
Proactively pushing data to the plausible target T is a job for the server, which needs to be aware of the targets currently displaying a QR code and of the recent interactions between mobiles and targets. Each target computer stores a cookie named “ctn” with a value of three letters, which lives for 36 hours. This ephemeral cookie is insufficient to uniquely identify a target and is used solely for the purpose of enabling “precasting” from the server and “prefetching” by the browser. The server detects the client B listening to T, looks up its cookie in the recent recipients of M, precasts the encrypted payload URL (the first Push), and lets the browser prefetch the encrypted picture. The target candidate silently feels a gentle breeze of incoming encrypted data.
But what happens when T is actually not the target of the current Share action from M? Not much. The “wrong” browser prefetches some encrypted data but can’t do anything with it. The necessary decryption key is only provided with the second Push, after the QR code has been scanned and we know the real target for sure.
Most of the time, T is the correct target, and the early download (prefetching) provides yet another head start:
In this example, the “gain” duration is equal to the “download” duration, shortening the total Share action. What’s more impactful is the sharp reduction in the delay after scanning. This is a key enhancement to the user experience! Aiming and scanning are active steps for the user, whereas the more frustrating passive final wait phase is now often under one second.
The Prefetch optimization kicks in for 38% of Share actions involving a single downscaled picture. 99% of the precast/prefetch operations involve only one target candidate. Prefetching saves 700 ms, which is half of the latency after scanning.