Obviously a fast network connection is a Good Thing, but Workbooks also works well over relatively slow links. There are a number of reasons for this but it boils down to the fact that the Desktop is downloaded once and thereafter a fairly small amount of traffic is required to cause windows to be drawn, picklists populated and grids filled out.

There are also some more in-depth reasons which I've just posted on our technical blog and which I'm copying here in case it's useful.  The summary, however, is that you should try things for yourself to verify that things really do run quickly from your location.

Workbooks is accessible worldwide, with any modern browser. We have users in Europe, the USA and as far afield as the South Africa, Thailand and Mauritius. The Desktop is a large amount of JavaScript, together with many assets. So why is it still fast to load the Desktop?

• We've gone for extremely high-capacity network connections - recently upgraded by our provider to 10 Gbit/s - with low latency to our nearest major peering points and especially through LINX.

• All our assets are packaged and do not cache-expire - built using Scott Becker's excellent Asset Packager plugin. So once they are downloaded they are not re-fetched until we release a new version of our software.

• Most interestingly, and most recently, we've adjusted our TCP/IP parameters to follow some neat tricks Google and Microsoft have been adopting recently.... I'd like to explain that here.

TCP/IP connections on a standard network stack often stall over high-latency (often this means "long distance") network connections because the sending client waits for an acknowledgement packet after a small number of packets have been sent.

Worse, this number doesn't increase much and for very long: it reduces even on TCP connections which use HTTP keepalive.  Our initial TCP window size has been bumped right up to 10 packets, which is a full 15K bytes (standard "slow start" settings would allow only 1 or 2 packets to be in transit before an acknowledgement is received). So we can have up to 120K bits in flight before we need an acknowledgement packet back from the far end. This is almost always long enough for all the data in a server response to a client request so windows get drawn on the Desktop with the minimum of delay.

Finally we've now adopted a congestion-control technique called 'CUBIC' which is much better for high-bandwidth but long-distance connections than our previously-adopted 'Reno'.

Background reading:

• http://news.ycombinator.com/item?id=1143692