The current lag is not caused by geographical location. Rather, it occurs due to three main reasons:

1. Heavy traffic in the bitshares network. As the endpoint node for the wallet, we need to handle the massive fan-out of all new incoming operations in the bitshares network (around 50x fan out). In this case, our bottleneck is the CPU, as that each active connection require CPU time to process each request.
2. Heavy DB load when computing statistics and distributing them. This is an inherited problem from btsbot, and it lies in the design choices the original developer choice in the database (mango). Mango is a bad db choice largely due to its read/write latch. As a write is blocking for all reads in the db and vice versa, which is different from SQL which has smaller lock granularity.
3. Scalability problem in the original btsbot algorithm. The original algorithm is an O(n^2) for many calculations, including the 28-day volume calculation, where n is the number of tx in the bitshares network.

We do have a plan to migrate the lag with our build #2, which will be open for public testing around February. One of the ways we are doing it is by reducing the traffic thru our servers by implementing a way for the wallet to work side by side with existing node infrastructure, allowing the client to connect to existing bitshares nodes to reduce the amount of data they will need to pull from our servers. The other ways we are addressing this problem is to migrate to SQL. Currently, we are still optimizing our SQL servers, but we are achieving 1k tx (3k tx per block) per second under our stress testing. (Compare to mongo db which tops around 200 tx per second --600 tx per block ) Lastly, we have written a linear time ( O(n)) algorithm for most of the O(n^2) calculation.