1.2　优化什么，何时优化？

和优化技术同等重要的是：知道什么时候不优化。过早优化会带来晦涩的代码和bug，优化很少执行的代码区域也没有必要。以帕莱托法则（即80-20法则）来看，20%的代码将占用80%的CPU周期。程序员应该集中于优化这20%、10%或5%，而忽略其他部分。这样bug会更少，大部分代码都保持了可读性，也保证了你的头脑清醒。

你可以用Firebug等性能测试工具，来了解哪些函数花费了绝大部分执行时间；然后检查这些函数并决定要优化的代码段。Firebug性能测试器依赖火狐（Firefox）浏览器，有些浏览器有自己的性能测试器。而老版本的浏览器则不一定有类似的工具。

图1-1是Firebug性能测试器的界面。在Console菜单，选择Profile来开始性能测试，然后再选择Profile来停止测试。然后Firebug会显示所有在开始和结束点之间被调用的JavaScript函数分析。所显示的信息如下所示。

图1-1　运行中的Firebug性能测试器

Function

被调用的函数名

Percent

在函数中所花费的时间和总时间的比例

Call

函数被调用的次数

Own time

在函数中所花费的时间（不包括对其他函数的调用）

Time

在函数中所花费的时间（包括对其他函数的调用）

Average

Own time的平均值

Min

函数的最快执行时间

Max

函数的最慢执行时间

File

函数所在的JavaScript文件

如果你能自己创建适合所有浏览器的性能测试集，可以提高开发效率，并在没有测试工具的浏览器上使用。它只是将相同的测试页面载入到每一个浏览器，然后阅读测试结果。它也可以用来迅速检查函数内的细微优化。“自定义代码性能测试”一节将讨论如何创建自己的性能测试集。

　警告

类似Firebug的调试器会给时间数值带来不小的误差。在执行性能测试之前，要确保关闭调试器。

“优化”是一个很宽泛的词，程序员可以从不同方面，以不同方式来对一个Web应用进行优化。

算法

应用程序是使用最有效的方法来处理数据的吗？代码优化没法修正一个差劲的算法。实际上，找对算法和DOM操作的高效一样，是保证应用快速运行最重要的因素之一。

有时，如果应用要求不高，一个慢但容易实现的算法就足够了。但如果性能是个问题，你也许需要检查研究一下当前所使用的算法。

本书不会讨论常见的搜索和排序等具体算法，因为读者可以在相关的计算机书籍和网络资源中找到许多关于它们的讨论。即使是游戏中涉及的3D图形学、物理和碰撞检测等这些更专业的问题和算法，也有很多书籍可以参考。

JavaScript

仔细检查调用得非常频繁的代码，在应用的某些关键区域中，对频繁执行部分的一个小小优化都会有不错的收益。

DOM和jQuery

DOM加jQuery是操纵Web页面非常方便的一种方式。但如果你没有注意到一些简单规则的话，也会成为性能重灾区。DOM搜索和操作比较慢，应该尽量避免。