In the past, we've had to either approximate the value by putting a timer at the start of our document, or use a cookie to store the time when the previous page's
onbeforeunload* event fired. Both approaches have their problems.
In the first case, the time measured tends to ignore the time it takes for the browser to do DNS lookups, open TCP connections, deal with TCP slowstart, and deal with latency introduced by the server-side application.
The second case excludes any traffic that either had no
onbeforeunload event (such as bookmarks or non-web clients) or had an
onbeforeunload event that we couldn't control (such as links from sites outside our domain).
When developing boomerang, we chose the latter approach. Even though we get fewer data points, the data is more representative of what users experience.
The introduction of the WebTiming API fixes the downside of this choice. If boomerang determines that it could not set
t_start (the time that navigation started), then it checks to see if the user's browser supports the WebTiming API. If it does, boomerang pulls the time out of the
At the time of this writing, Internet Explorer 9 supports WebTiming in the
window.msPerformance object. Google has announced plans to support the
window.webkitPerformance object, and Mozilla will probably add
window.mozPerformance to Firefox. No word from Opera yet. Older versions of Chrome supported a
window.csi() method that exposed similar information, but with a different API.
I'm also pleased to note that with Commit 83f776772c9604023b3, boomerang supports all of these implementations, in addition to its own cookie-based measures.
*Opera doesn't support
onbeforeunload, so on Opera we use the
onunload event instead.