You might be surprised at just how variable the HTTP response times are in your web application. Take a look at this 24-hour example:
Crucially, the variance in this example is caused by the application response time, rather than the network. That’s the blue Exec component, not TCP or Transfer components.
Variance-of-latency isn’t a huge problem with traditional page-refresh-response websites and applications, but certainly does present an annoyance to your users. When your app starts to get cleverer and offers AJAX goodies, however, the problem becomes more serious.
Sometimes, your user clicks repeatedly in futility, wondering what’s going on and why she is getting no response. Other times she’s not sure if anything is working at all.
So our Happy User rapidly becomes a Sad User. Click… wait… wait. She’s not feeling so empowered by your application at this point.
A more problematic scenario is that out of sequence AJAX responses will break your UI. Many developers using mainstream (read: simple to deploy) libraries fail to code precautions against this.
And it’s easy to see why: By now, most AJAX-happy developers are aware of latency issues, and latency is quite simple to emulate in a test environment.
Variability-of-latency is not getting enough airtime – most likely because few people are actually measuring it as a part of their build process.
It’s not the network.
Raise the issue with the developers and they will probably start a delightful discourse on the “best-effort” nature of internet pipelines, asymmetric routing, and similar vagaries of internet infrastructure. The implication being that the user is at fault because they chose to use your app from a free wifi hotspot in Turkmenistan.
Our graph above, however, shows that the fault lies squarely with the application being unable to offer consistent response times. HTTP network overhead is just a tiny fraction of the total – and runs at a consistent 89ms anyway.
The lesson is: Fully understand your application performance and work to improve its consistency, particularly during peak periods. The underlying network is rarely to blame.