探查器绝对是获取数字的好方法，但根据我的经验，感知性能对用户/客户来说是最重要的。例如，我们有一个带有 Ext 手风琴的项目，它可以扩展以显示一些数据，然后是一些嵌套的 Ext 网格。一切其实都渲染得很快，没有一个操作需要很长时间，只是一次渲染了很多信息，所以用户感觉很慢。

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

这些天来，Chrome的探查和其他工具的普及和易于使用，因为是console.time()，console.profile()和performance.now()。Chrome 还为您提供了一个时间线视图，它可以向您显示导致您的帧速率下降的因素、用户可能正在等待的位置等。

查找所有这些工具的文档非常简单，您不需要为此提供 SO 答案。7 年后，我仍然会重复我原来的答案的建议，并指出你可以让缓慢的代码在用户不会注意到的地方永远运行，而在他们所做的地方运行非常快的代码，他们会抱怨相当快的代码不够快。或者您对服务器 API 的请求花费了 220 毫秒。或者其他类似的东西。重点仍然是，如果你拿出一个分析器去寻找工作要做，你会找到它，但它可能不是你的用户需要的工作。

我确实同意感知性能真的很重要。但有时我只想找出做某事的哪种方法更快。有时差异是巨大的，值得了解。

你可以只使用 javascript 计时器。但我通常得到使用原生的浏览器（目前还在Firefox和Safari）devTool方法更加一致的结果console.time()：console.timeEnd()

我如何使用它的示例：

var iterations = 1000000;
console.time('Function #1');
for(var i = 0; i < iterations; i++ ){
    functionOne();
};
console.timeEnd('Function #1')

console.time('Function #2');
for(var i = 0; i < iterations; i++ ){
    functionTwo();
};
console.timeEnd('Function #2')

更新 (4/4/2016)：

Chrome canary 最近添加了Line Level Profiling the dev tools sources 选项卡，让您准确了解每行执行所需的时间！

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

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

试试jsPerf。它是一个在线 javascript 性能工具，用于对代码片段进行基准测试和比较。我用它所有的时间。

大多数浏览器现在都在performance.now(). 它优于new Date()性能测试，因为它独立于系统时钟运行。

用法

var start = performance.now();

// code being timed...

var duration = performance.now() - start;

参考

• https://developer.mozilla.org/en-US/docs/Web/API/Performance.now()
• http://www.w3.org/TR/hr-time/#dom-performance-now