测量客户端页面加载时间的最佳方法是什么?

发布于 2024-07-13 11:16:46 字数 359 浏览 4 评论 0原文

我希望监控我们网站的最终用户体验,并将其与服务器端已记录的计时信息链接起来。 我的假设是,这将需要 javascript 在请求开始时 (window.onbeforeunload) 和加载结束时 (window.onload) 捕获时间戳。 基本上是这样的 - “测量 Web 应用程序响应时间:与客户见面

  1. 有更好的方法吗?
  2. 我应该期待什么样的性能损失(数量级)?
  3. 结果有多好?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

微暖i 2024-07-20 11:16:46

还有雅虎的 Boomerang

具有 Jiffy 和 Episodes 中不存在的一些高级功能。 还支持在支持 NavigationTiming API 的浏览器 (Chrome) 6、IE 9)

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)

橘虞初梦 2024-07-20 11:16:46

为了完整起见,您现在可以在某些现代浏览器中使用导航计时 API: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);
}

第三方编辑

基于caniuse.com 导航计时 今天得到广泛支持 (10/2016)

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)

洛阳烟雨空心柳 2024-07-20 11:16:46

编辑(2013):尝试使用 Boomerang 代替,就像 @yasei-no-umi 建议的那样。 它得到积极维护。

-- 旧答案 --

我们使用 Jiffy

使用和修改非常简单——我们编写了自己的服务器端代码(而不是Jiffy的Apache + perl)并使用了Jiffy的JS。

关于性能损失——客户端没有。 JS 本身速度非常快,并且可以在页面加载后使用 XHR 完成向服务器的报告,这不会影响用户体验。 在服务器端,您将收到两倍的请求。 如果这是一个瓶颈,您可以设置一个不同的服务器来专门用于计时响应。

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.

你的他你的她 2024-07-20 11:16:46

使用 yslow (火狐扩展)之类的东西怎么样?

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

幸福不弃 2024-07-20 11:16:46

Jiffy 的替代方案是 剧集

两者都涉及对 Javascript 进行检测以跟踪各种计时,并将这些计时记录在中央服务器上。

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.

沧桑㈠ 2024-07-20 11:16:46

我们在页面中有一个“回调”(一个 1x1 透明 GIF 图像,带有代表页面渲染 ID 的参数),将“查看的页面”记录到我们的数据库中。 这是与页面本身记录具有相同 ID 的记录,并且当渲染完成时我们有一个日志条目。

因此,我们有以下时间:

  • 页面准备开始
  • 页面准备/响应完成
  • 渲染完成后客户端回拨

帮助了解“慢”(CPU 或 ISP/带宽)的客户端

PS 不回拨的页面渲染也很有趣 -用户单击关闭(假设该会话中呈现的其他页面确实记录了 Phone Home)

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)

夜还是长夜 2024-07-20 11:16:46

我对这些方法很怀疑。 其中一些方法比必要的更复杂,我质疑这些数据的准确性。 我要做的就是让测试人员访问各种网络并使用 Firebug 之类的东西:

http://getfirebug.com/< /a>

管它呢; 这是最近提交给 SOSP 的一篇关于名为 AjaxScope 的工具的有趣论文。 有趣的是,这是一篇由 MS Research 发表的学术文章,其中显示 Firefox 的 Javascript 实现在某些情况下比 Internet Explorer 的性能好很多倍。 :)

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

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

夏至、离别 2024-07-20 11:16:46

我们倾向于使用以下组合:

Firefox:
Web 开发者工具栏
Firebug
YSlow

IE:
Fiddler

在所有这些中,我发现 YSlow 提供了有关您可以做什么的最佳信息来缩短加载时间,但 Fiddler 可以提供有关您可以通过网络期待的最佳整体信息,甚至可以模拟不同的网络速度。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文