现在你已经知道足够快的门槛了，下一步是研究如何才能测量JavaScript的执行速度，以确定它是否超出前面提到的范围。

           现在你已经知道足够快的门槛了，下一步是研究如何才能测量JavaScript的执行速度，以确定它是否超出前面提到的范围。

      通过人的观察来测量延迟时间虽不精确，却是最简单最直接的方法：只要在目标平台上运行一下应用程序，然后确定性能是否足够快。因为确保用户界面性能足够好的目的就是让使用者感到愉悦，所以这样做测试其实是否足够快。因为确保用户界面性能足够好的目的就是让几秒来量化延迟，所以可以使用粗略的分类。

      有些工具能对代码执行时间进行自动测量，但它们通常用于各种不同的目的。这些性能分析器不是用来确定函数的精确执行时间的，而通常用于确定执行一组函数的相对时间；也就是说它们是用来查找瓶颈或运行最快的代码快的。

     “Time/时间”列表示JavaScript解析器在性能分析期间执行指定函数的总耗时。通常函数执行会调用其他的函数，“Own Time”列表特定函数自身而不包含任何它调用过的其他函数的耗时。

      然而你可能会认为上述或其他类似与时间相关的列反映的就是对函数执行时间的精确测量，但事实上性能分析器也会受到外在的影响——类似物理学中的观察者效应：观察代码性能的行为改变了代码的性能。

      性能分析器用两个基本行为策略来说明基础权衡关系：要么在要测量的代码中加入特定代码来收集性能统计信息，要么在特定时间中实时检验具体执行的代码来监视运行的代码来监视运行时间。这两种策略中，后者使需要分析的代码性能失真更少，但代价是获取到的数据质量会相对低一些。

      Firebug的性能分析器只能在Firefox自己的进程中执行，他有可能造成正在测量的代码损失性能，因此Firebug会使测量结果进一步失真。

      不过，“percent/百分比”证明了Firebug测量相对执行时间的用处：你可以在网页界面上执行一个高级别的任务，然后执行Firebug的性能分析器去查看哪些函数消耗的执行时间最多，最后在集中在这些函数上面进行优化工作。