What is the best way to measure Client Side page load times?

Question

I'm looking to monitor the end user experience of our website and link that with timing information already logged on the server side. My assumption is that this will require javascript to to capture time stamps at the start of request (window.onbeforeunload) and at the end of loading (window.onload). Basically this - "Measuring Web application response time: Meet the client"

1. Is there a better approach?
2. What kind of performance penalty should I be expecting (order of magnitude)?
3. How good are the results?

Answer 1

EDIT (2013): try Boomerang instead, like @yasei-no-umi suggests. It's actively maintained.

-- old answer --

We use Jiffy.

It's very simple to use and modify - we wrote our own server-side code (instead of Jiffy's Apache + perl) and used Jiffy's JS.

Regarding a performance penalty - there isn't one on the client side. The JS itself is trivially fast, and the reporting back to the server can be done with an XHR after page load, which affects nothing in the user experience. On the server side you'll get twice as many requests. If that's a bottleneck, you could set up a different server just for the timing responses.

Answer 2

There is also Boomerang from Yahoo.

Has some advanced features not existing in Jiffy and Episodes. Also support Navigation Timing API in browsers that support it (Chrome 6, IE 9)

Answer 3

For completeness' sake, you can now use the Navigation timing API in some of the modern browsers: https://developer.mozilla.org/en-US/docs/Navigation_timing

function onLoad() { 
  var now = new Date().getTime();
  var page_load_time = now - performance.timing.navigationStart;
  console.log("User-perceived page loading time: " + page_load_time);
}

3rd party edit

Based on caniuse.com navigation timing is widely supported today (10/2016)

Answer 4

What about utilizing something like yslow ( a firefox extension)?

Answer 5

An alternative to Jiffy is Episodes.

Both involve instrumenting your Javascript to keep track of various timings, and logging those timings on a central server.

Answer 6

We have a "call back" (a 1x1 transparent GIF image with a parameter representing the ID for the page render) in the page that logs a "Page viewed" to our database. That is records with the same ID that the page itself is recorded, and we have a log entry when our rendering finishes.

So we have time of:

• Page preparation started
• Page preparation / Response finished
• Client phoned-home when rendering completed

Helps with understanding clients that are "slow" (CPU or ISP/bandwidth)

P.S. Page renders that do not call home are of interest too - the user clicked-off (assuming that other page renders in that session did record a Phone Home)

Answer 7

I'm pretty dubious of these methods. Some of these methods are more complex than necessary and I question the accuracy of this data. What I'd do is have testers go to various networks and use something like Firebug or something:

http://getfirebug.com/

For the heck of it; here is an interesting paper recently submitted to SOSP on a tool called AjaxScope. Interestingly enough, it is a scholarly article, presented by MS Research, that shows Firefox's Javascript implementation performing many times better than Internet Explorer in a few cases. :)

http://research.microsoft.com/en-us/groups/rad/sosp07.pdf

Answer 8

We tend to use a combination of:

Firefox: Web Developer Toolbar Firebug YSlow

IE: Fiddler

out of all of these, I've found YSlow gives the best information on what you can do to improve your load times, but Fiddler gives the best overall information on what you can expect over the wire, and can even simulate different network speeds.