How to Reduce Latency

As a developer of tools to simulate latency, many people ask us, “How can I reduce the latency?”
We’re networking people, so to us, “latency” means network latency, the
amount of time it takes a packet to cross the network from sender to
receiver.  However, for applications people or end users, “latency” can have a very different meaning — the amount of time that a user has to wait from the time he takes an action, clicking a link for example, to the time when the action is completed such as a web page being fully displayed.  We usually refer to that as application responsiveness or lag, but it’s
sometimes called application latency.
Network latency is mostly a function of distance, so it can be difficult to
reduce substantially.  Of course, switching from a satellite network or even
a wireless network to a terrestrial network can make a big difference.  And
especially for shorter distances, finding a carrier that has the most direct
connection between your two sites may help.  Getting rid of any congestion on the network can reduce queueing delay.  But in most situations, the latency is a simple function of the distance between the two sites and that doesn’t change.
What the end user cares about, whether playing a networked game, surfing the web, or opening a powerpoint presentation from the company file server, is application responsiveness. And that often can be improved.
Taking the simple example of downloading a large file, we usually use FTP.
If the network latency is high or there is significant packet loss, changing
the TCP window settings and other parameters can improve FTP performance dramatically.  Or instead of using FTP, we could use a different data transfer application entirely.  Or if neither of those options are
convenient, we can insert a WAN optimization device onto the network.
Similarly, other applications can be fast or slow to respond depending on
many factors: the size of each of the elements to be downloaded, the number of separate round trips required to load all of the elements, and the protocols used and their settings. Each of these is affected by the network latency as well as the amount of bandwidth available and any packet loss.
Applications that may be extremely responsive on the local network with
gigabit bandwidth and no network latency or packet loss may be painfully
sluggish in real world.  Applications therefore need to be tested with real
world WAN conditions prior to deployment, and ideally during the development phase while it is still easy to optimize the design for a wide range of user conditions.
So our answer is this: you probably can’t change the network latency, but by simulating the network latency and other network conditions, you can
optimize the application design to change what matters – the application
responsiveness.