剖析器绝对是获取数据的好方法，但根据我的经验，对用户/客户来说，感知性能才是最重要的。例如，我们有一个带有Ext手风琴的项目，它展开来显示一些数据，然后显示一些嵌套的Ext网格。所有内容都呈现得非常快，没有一个操作需要很长时间，只是有很多信息同时呈现，所以用户感觉很慢。

我们“修复”了这个问题，不是通过切换到一个更快的组件，或优化一些方法，而是通过先呈现数据，然后用setTimeout呈现网格。所以，信息先出现，然后网格会在一秒钟后出现。总的来说，这样做需要稍微多一点的处理时间，但对于用户来说，感知性能得到了改善。

如今，Chrome分析器和其他工具普遍可用，而且易于使用 Console.time () (mozilla-docs, chrome-docs) Console.profile () (mozilla-docs, chrome-docs) performance.now () (mozilla-docs) Chrome也给你一个时间轴视图，可以告诉你什么是杀死你的帧率，用户可能在哪里等待，等等。

Finding documentation for all these tools is really easy, you don't need an SO answer for that. 7 years later, I'll still repeat the advice of my original answer and point out that you can have slow code run forever where a user won't notice it, and pretty fast code running where they do, and they will complain about the pretty fast code not being fast enough. Or that your request to your server API took 220ms. Or something else like that. The point remains that if you take a profiler out and go looking for work to do, you will find it, but it may not be the work your users need.

我认为JavaScript性能(时间)测试已经足够了。我在这里找到了一篇关于JavaScript性能测试的非常方便的文章。

剖析器绝对是获取数据的好方法，但根据我的经验，对用户/客户来说，感知性能才是最重要的。例如，我们有一个带有Ext手风琴的项目，它展开来显示一些数据，然后显示一些嵌套的Ext网格。所有内容都呈现得非常快，没有一个操作需要很长时间，只是有很多信息同时呈现，所以用户感觉很慢。

我们“修复”了这个问题，不是通过切换到一个更快的组件，或优化一些方法，而是通过先呈现数据，然后用setTimeout呈现网格。所以，信息先出现，然后网格会在一秒钟后出现。总的来说，这样做需要稍微多一点的处理时间，但对于用户来说，感知性能得到了改善。

如今，Chrome分析器和其他工具普遍可用，而且易于使用 Console.time () (mozilla-docs, chrome-docs) Console.profile () (mozilla-docs, chrome-docs) performance.now () (mozilla-docs) Chrome也给你一个时间轴视图，可以告诉你什么是杀死你的帧率，用户可能在哪里等待，等等。

Finding documentation for all these tools is really easy, you don't need an SO answer for that. 7 years later, I'll still repeat the advice of my original answer and point out that you can have slow code run forever where a user won't notice it, and pretty fast code running where they do, and they will complain about the pretty fast code not being fast enough. Or that your request to your server API took 220ms. Or something else like that. The point remains that if you take a profiler out and go looking for work to do, you will find it, but it may not be the work your users need.

我们总是可以通过简单的date对象来测量任何函数所花费的时间。

var start = +new Date();  // log start timestamp
function1();
var end =  +new Date();  // log end timestamp
var diff = end - start;

下面是一个用于时间性能的可重用类。示例包含在代码中:

/*
     Help track time lapse - tells you the time difference between each "check()" and since the "start()"

 */
var TimeCapture = function () {
    var start = new Date().getTime();
    var last = start;
    var now = start;
    this.start = function () {
        start = new Date().getTime();
    };
    this.check = function (message) {
        now = (new Date().getTime());
        console.log(message, 'START:', now - start, 'LAST:', now - last);
        last = now;
    };
};

//Example:
var time = new TimeCapture();
//begin tracking time
time.start();
//...do stuff
time.check('say something here')//look at your console for output
//..do more stuff
time.check('say something else')//look at your console for output
//..do more stuff
time.check('say something else one more time')//look at your console for output

UX Profiler从用户的角度来解决这个问题。它将所有浏览器事件、网络活动等由用户操作(点击)引起的事件进行分组，并考虑到延迟、超时等所有方面。