Many people would have you believe that latency is the only real KPI that you should be worried about when analyzing your website performance. There are even numerous statistics that illustrate the slightest bit of slowdown can negatively impact your business. In fact, although these stats are a bit dated, I’ve collected a few below:
- Amazon found every 100ms of latency cost them 1% in sales.
- Google found an extra .5 seconds in search page generation time dropped traffic by 20%
- A broker could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind the competition.
But have we become “latency myopic?” Many organizations have become hyper-focused on latency…as if it’s possible to drive it to zero. But, as I’ll explain below, that’s not possible and may, in fact, be detrimental to the business.
In a recent presentation I watched from Dave McCrory, the CTO of Basho (a NoSQL database company), latency is a compounding problem. Depicted in one of his slides below, as a request is processed it goes through multiple “layers” of latency—CPU, computer bus, computer memory, the network, the disk, etc. At each point in the process, latency (in this case nanoseconds) is added to processing and responding to the request.
If the above graph holds true (at the most basic level of retrieving something from disk) then it’s impossible to completely remove latency from delivery. But what if being hyper focused on performance improvement was also a detriment to the business?
In his book David and Goliath, Malcolm Gladwell explored the concept of the “Inverted-U curve” as it relates to parenting and money. His argument was that it was difficult to parent when you are poor, it becomes easier with some money, but it becomes harder again when you get rich. Using a little imagination, it’s not hard to understand why this is the case. When kids grow up in a rich family, they become self-entitled. It becomes as hard to parent them as if they didn’t have any money and see no hope in the world.
What does parenting, Malcolm Gladwell, and inverted-U curves have to do with website performance? Everything. Because before you dismiss this analogy out of hand, the psychologists Barry Schwartz and Adam Grant argue that nearly everything of consequence follows the inverted-U “Across many domains of psychology, one finds that X increases Y to a point, and then it decreases Y…. There is no such thing as an unmitigated good. All positive traits, states, and experiences have costs that at high levels may begin to outweigh their benefits.” What Schwartz and Grant are trying to say is that everything has a sweetspot where X and Y are maximized. How does the inverted-U curve impact website performance? Well, at first, resources expended on trying to remove latency are rewarded with significant improvements (as X and Y are maximized). But as more resources are thrown at removing latency, little to no incremental or perceptible improvement is shown.
What's more, as intimated in the inverted-U curve analogy, continuing to focus on the performance of a website may actually be detrimental to the business by expending valuable resources (time and money) that could be better allocated to other, more important projects. Think about it. The human eye blink is approximately 450ms and yet we focus performance improvement on tens of milliseconds. Look at this data by Cedexis:
This data table represents CDN performance. If you look at the 50th percentile, you’ll see that performance (between first and last) is only 11ms, a virtually imperceptible length of time. And yet organizations, hyper focused on latency, continue to measure and judge their website performance by such incidental numbers all the while throwing time and money at attempting to get latency closer to zero.
Rather than chase the unicorn of increasingly less latency, perhaps what organizations should instead focus on are major performance improvements they can make at the beginning of that curve (i.e., to get to the sweetspot):
- CDN—utilizing a content delivery network, with caches closer to the end user, can dramatically improve website performance, especially if no other tuning has been done. Some CDNs even provide dynamic content acceleration which provides performance improvement for objects that cannot be cached (i.e., a dynamic web page that is generated on the fly).
- Storage—obviously, as indicated in the illustration from McCrory’s presentation, storage can have a significant impact on latency. Where you store your website objects makes a difference. That’s why using a CDN, where objects can be stored in cache (often times, this storage is SSD-based) closer to the end user, can mitigate some of the network-based latency involved in retrieving objects.
Together, these three changes can significantly improve overall website performance, often times by several seconds. Beyond that? Continuing to tune website performance and squeeze out every millisecond of latency is just a waste of time and energy.
So how do we fix this problem of latency myopia? The first way is to stop worrying about latency and set a threshold for website performance that’s “good enough” (i.e., the sweetspot in the inverted-U graph). Second, and perhaps more important, is to evaluate a website experience (i.e., KPIs) by more than just performance. Although many organizations do measure interactivity as it relates to usability, they are not often tying the success of their web experience to those measurements. Performance is only one website characteristic that needs to be measured. And, as just one component of overall web experience success, it doesn’t deserve any more resources to improving than, does, say the website design.
Are you wasting valuable time and money chasing the latency rabbit down the hole? Stop. Start using a CDN (especially one with integrated cloud storage for your origin content). Set a “good enough” threshold. And then start examining other elements of your web experience. By focusing on shaving off those 5 milliseconds, you may be causing more harm than good.
 Gladwell, Malcom. David and Goliath. Pg 52.