问题
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"
- Is there a better approach?
- What kind of performance penalty should I be expecting (order of magnitude)?
- How good are the results?
回答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.
回答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)
回答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)
回答4:
What about utilizing something like yslow ( a firefox extension)?
回答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.
回答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)
回答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
回答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.
来源：https://stackoverflow.com/questions/547458/what-is-the-best-way-to-measure-client-side-page-load-times