We all know intrinsically that website performance is important. It has a tremendous impact on all of the business KPIs that measure the success of our online endeavor. I think website performance gets so much attention for two reasons: (1) it’s the most obvious symptom for bad results and (2) and it is easy to measure.
In my larger philosophical views on Customer Experience (CX) I’ve suggested…
PX > CX > UX = #usable + #feelsfast + #emotive
Feelsfast here represents “a lack of perceived latency.”
15 years ago, when I first started thinking about web performance, we only had network oriented metrics to understand web page performance. Today, there are a larger set of collectible metrics to measure many aspects of the spectrum on User Experience (UX). And today’s web applications, because they are pretty fat clients, must take client-side performance into account as well.
We are constantly reminded of the importance of performance by vendors, the media and customers through their actions.
What is the most important metric to measure web performance as a KPI? It’s the one that best represents User Experience or a lack of perceived latency.
We have network metrics. These are old school metrics that focus on how long it takes your server and the network to delver web page resources to the browser’s network layer.
- DNS lookup time – time to resolve DNS name
- TCP connect time – time to TCP connect
- SSL handshake time – time to perform SSL handshake
- Time to first byte – time to receive the first packet of data
- Time to receive the data – time to receive the data
- Fullpage time – time to load the web page and all it’s resources
Most of today’s modern network browsers supplement this with a richer set of data based on the W3C standards for navigation timings:
- navigationStart – time that the action was triggered
- unloadEventStart – time of start of unload event
- unloadEventEnd – time of completion of unload event
- redirectStart – time http redirection begins
- redirectEnd – time http redirection completes
- fetchStart – time that request begins
- domainLookupStart – time of start of DNS resolution
- domainLookupEnd – time DNS resolution completes
- connectStart – time when tcp connect request begins
- connectEnd – time when tcp connect completes
- secureConnectionStart – time just before secure handshake
- requestStart – time that the browser requests the resource
- responseStart – time that the browser receives first packet of data
- responseEnd – time the browser receives the last byte of data
- domLoading – time that the document object is created
- domInteractive – time when the browser finishes parsing the document
- domContentLoadedEventStart – time just before DomContentLoaded event
- domContentLoadedEventEnd – time just after DOMContentLoaded event
- domComplete – time when the load event of the document is completed
- loadEventStart – time when the page load event is fired
- loadEventEnd – time when the page load event completes
This is a nice visual of the W3C timings.
And we have visual timing metrics available from various tools:
- IE11 brings us msFirstPaint as part of the browser timings
- webpagetest.org gives us start render, filmstrip view, and the innovative speed index
- AlertSite.com can provide visual capture and metrics for FirstPaint and Above the Fold using Firefox
How do you choose which web performance metric has the most value as a KPI when all of these have some value? The key is to identify, for any particular monitored application or web page, which metric best represents a users perception of latency, in other words, if it feels fast. This is likely one of the more modern metrics – loadEventEnd, FirstPaint, Speedindex, Above the fold.
Once selected, this #feelsfast metric should become a critical business KPI and tracked and managed as such.
Are you giving the web performance component of UX enough attention?