Monthly Archives: March 2014

Display w3c navigation timings for any web page

I’ve been trying to find a tool that will display all the w3c navigation timings for any web page that I might be browsing. I was surprised when I didn’t find it in Chrome dev tools (really?) nor in speedtracer nor in the format I wanted available Chrome extensions (*hint: product opportunity for someone).

I actually considered writing a Chrome extension myself to show the web performance data from the navigation timings for any web page for a whole afternoon while I was creating my first “Hello World” extension, but I would be slow trying to learn the necessary javascript and messaging protocol Google requires for the extension.

And then I came across this “adorable” bookmarklet from @kaaes that does just that.
breaking_down_onLoad

All you have to do is drag the bookmarklet to your bookmarks and click it for any web page you are browsing and voila!

w3c_nav_timings

So far, this is the handiest tool I have found to get a quick glimpse at the nav timings for your website. These web performance timings are becoming the defacto standard and that will be even more true when browsers support the forthcoming resource timings (thus giving us the waterfall report as well).

Hope you find this a useful bit of kit for your web performance tool belt.
And a shout out to @kaaes for sharing this with everyone!

Ken

How to select the most important web performance metric as a KPI – #feelsfast

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.

timing-overview

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?

Ken